Why do so few people know the difference between arrays and pointers.

[E. Robert Tisdale]

This assertion directly contradicts the C standard,

The standard be damned.

which specifically defines an object as a region of storage.
It *is* a region of storage, not 'might be' or 'could be'.

You ignored my example above. Is y an object or not?
Is y [still] an object if the C compiler optimizes it away
and computes

int z = 3*(x + 1);

directly?

 

[Keith Thompson]

Keith Thompson wrote: [...]

It's an expression, and it has a value, but it's not an object.
Evaluation of the expression may or may not involve
an int-size region of storage containing the value 42;
that's an implementation detail,
irrelevant to C's definition of "object".

Are we to infer that
the existence of an object depends upon the implementation?

No, the existence of an object depends on the definition in the
standard.

For a declared object, such as "int y;", the standard says y is an
object. An implementation is allowed not to allocate storage for it,
if this optimization doesn't change the effect of the program, but
it's still an object in the abstract machine.

For an expression such as 42, the standard does not say that there is
an object associated with the value of the expression. An
implementation may allocate an int-sized region of storage holding the
value 42, but there's still no object in the abstract machine.

Optimization does not affect whether something is an object as defined
by the standard.

(I'm writing this for the benefit of other readers, since ERT is
unlikely to be convinced by anything I write.)

 

[Alex Monjushko]

Mike Wahler wrote:

The standard be damned.

You ignored my example above. Is y an object or not?
Is y [still] an object if the C compiler optimizes it away
and computes

int z = 3*(x + 1);

directly?

I believe that in this case the "as if" rule comes into effect.
It makes absolutely no difference whether 'y' is optimized away
or not. In a context where it would make a difference the optimizer
can't get rid of it.

Therefore, 'y' is an object, as far as you can tell in terms of
the C standard. Assembler output notwithstanding.

 

[Keith Thompson]

E. Robert Tisdale wrote: [...]

In C, an object is something *could* occupy storage.

This assertion directly contradicts the C standard,

The standard be damned.

That's a perfectly valid attitude. If you don't like the standard, or
if you just want to ignore it, you're absolutely free to do so. If
you want to program in some non-standard dialect of C, or of some
C-like language, go right ahead. There are over 6 billion people on
this planet; probably at least 5.9 billion of them aren't even aware
that the C standard exists (and if those numbers are off, the point is
still valid).

What mystifies me is why you choose to hang out here in comp.lang.c,
where we discuss the C programming language as defined by that damned
standard.

If you want to leave, nobody here is going to try to stop you. We'll
be fine. Really.

Bye.

 

[CBFalconer]

Uncalled for, but it did make me laugh...

You haven't suffered through Trollsdale postings ad nauseam.

 

[E. Robert Tisdale]

No, the existence of an object depends on
the definition in the standard.

I suppose that it also depends upon the code.

For a declared object, such as "int y;",
the standard says y is an object.
An implementation is allowed not to allocate storage for it,
if this optimization doesn't change the effect of the program,
but it's still an object in the abstract machine.

This appears to be consistent with my assertion that
"and object is a value that *could* occupy storage.

For an expression such as 42, the standard does not say that
there is an object associated with the value of the expression.
An implementation may allocate an int-sized region of storage
holding the value 42,
but there's still no object in the abstract machine.

int x = 42;

How does the "abstract machine" know that
x is initialized with the value 42?

A C program is correspondence from the programmer to the C compiler
and not any underlying abstract [or concrete] machine.

Optimization does not affect
whether something is an object as defined by the standard.

According to Brian W. Kernighan and Dennis M. Ritchie,
"The C Programming Language", Appendix A: C Reference Manual,
Section 5. Objects and lvalues:
" An object is a manipulatable region of storage;
an lvalue is an expression referring to an object.
An obvious example of an lvalue expression is an identifier.
There are operators which yield lvalues: for example,
if E is an expression of pointer type,
then *E is an lvalue expression
referring to the object to which E points.
The name ``lvalue'' comes from the assignment expression E1 = E2
in which the left operand E1 must be an lvalue expression."

Notice that K&R don't specify that constants are not objects.
The term ``object'' is introduced to help explain
the notion of ``lvalue'' but it is flawed.
It appears to imply that objects are *always* variables
which was true in the original definition of C.
Constants were always *literal* constants.
The C 89 standard introduced the ``const'' keyword
to qualify "read-only" storage and the const variable oxymoron.
This is a fundamental flaw in the design of the C language.
No redefinition of ordinary English words like object
is going to resolve it.


C programmers are *not* true believers.
The C standards documents are *not* religious dogma.
They were *not* carved in stone by God
and brought down from Mount Sinai by Moses.
They were written by human beings and, in cases like this,
they expose the muddled thinking of those human beings.
They deserve the same critical skepticism that you apply
to articles submitted to the comp.lang.c newsgroup.

 

[E. Robert Tisdale]

Keith Thompson wrote:

[Love it or leave it.]

Religious intolerance?

 

[CBFalconer]

.... snip ...
.... snip ...

If you want to leave, nobody here is going to try to stop you.
We'll be fine. Really.

Maybe we should take a straw vote. Three options:

a. Want to stop ERT from leaving:
b. Encourage ERT to leave :
c. Indifferent to ERT existence :

 

[Kelsey Bjarnason]

[snips]

int x = 42;

How does the "abstract machine" know that
x is initialized with the value 42?

Could be any number of ways. You're thinking in terms of the following
sequence of operations:

x dw (?)
mov [x], 42

In the binary, then, we might see a byte sequence along the lines of:

....
00 00 00 00 [storage space for x]
....
2a 00 00 00 [value of 42]

The code reads the literal value 42 and stores it into the space reserved
for x. 42 is thus "separate" from x in some sense. On the other hand,
the byte sequence could simply be:

.....
2a 00 00 00 [storage space for x, with the 42 hardcoded in place]
.....

Now there's no conceptual separation of the 42 and x - no separately
stored values. In the former case, you could, if you wanted, modify the
bits in the value for 42 *without* affecting the value in x; in the latter
case you can't, as the two are in no manner whatsoever separate entities.

That is to say, the 42 is not an object; it has no independant storage, no
address to be taken, nothing. It simply does not exist except as the
(current) value of x.

A C program is correspondence from the programmer to the C compiler and
not any underlying abstract [or concrete] machine.

The standard is a contract, of sorts; the developer writes according to
its rules, the compiler compiles according to its rules. The standard
defines how operations occur in relation to an abstract machine.

" An object is a manipulatable region of storage;

You can't manipulate 42; you can only assign from it.

C programmers are *not* true believers. The C standards documents are
*not* religious dogma.

No, they're not - they are the set of rules which compilers are expected
to follow to produce correct results, and which developers are expected to
follow to get the correct results.

brought down from Mount Sinai by Moses. They were written by human
beings and, in cases like this, they expose the muddled thinking of
those human beings.

There's not much unclear here.

 

[Kelsey Bjarnason]

[snips]

The standard be damned.

The VB channel is down the hall.

 

[Joona I Palaste]

No, they're not - they are the set of rules which compilers are expected
to follow to produce correct results, and which developers are expected to
follow to get the correct results.

There's not much unclear here.

I think ERT fails to understand the concept of a standard.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Outside of a dog, a book is a man's best friend. Inside a dog, it's too dark
to read anyway."
- Groucho Marx

 

[E. Robert Tisdale]

int x = 42;

How does the "abstract machine" know that
x is initialized with the value 42?

Could be any number of ways. You're thinking in terms of the following
sequence of operations:

x dw (?)
mov [x], 42

In the binary, then, we might see a byte sequence along the lines of:

....
00 00 00 00 [storage space for x]
....
2a 00 00 00 [value of 42]

The code reads the literal value 42 and stores it into the space reserved
for x. 42 is thus "separate" from x in some sense.
On the other hand, the byte sequence could simply be:

.....
2a 00 00 00 [storage space for x, with the 42 hardcoded in place]
.....

Now there's no conceptual separation of the 42 and x - no separately
stored values. In the former case, you could, if you wanted, modify the
bits in the value for 42 *without* affecting the value in x; in the latter
case you can't, as the two are in no manner whatsoever separate entities.

That is to say, the 42 is not an object;
it has no independant storage, no address to be taken, nothing.
It simply does not exist except as the (current) value of x.

Only if x is a static variable.
Not if x is an *automatic* variable.
In this function:

int f(void) {
static
int x = 42;
return x + 1;
}

x may be initialized by the compiler as you suggest above
but, in this function:

int f(void) {
int x = 42;
return x + 1;
}

x must be re-initialized to the value 42
*every* time that the function f(void) is invoked.
If 42 is small enough,
the compiler can store it in a "load immediate" instruction
as you have suggested above,
but it *must* store the value 42 somewhere.
If the fact that storage is reserved for a value makes it an object,
then 42 is an object.

 

[Kelsey Bjarnason]

[snips]

Only if x is a static variable.

Thus demonstrating that 42 is not an object, as if it were, it would
_always_ be an object. Yes, and?

x may be initialized by the compiler as you suggest above but, in this
function:

int f(void) {
int x = 42;
return x + 1;
}
}

So the compiler generates a hardcoded value of 42 at the address of x, as
I noted in the second case, copying x to modifiable memory on write.
Still no problem, still not even conceptually an object for 42.

 

[Mike Wahler]

The standard be damned.

Well, this ends the discussion. The language I'm discussing
is *defined* by that standard. If that language isn't
what you're referring to, this discussion is pointless.

which specifically defines an object as a region of storage.
It *is* a region of storage, not 'might be' or 'could be'.

You ignored my example above. Is y an object or not?
Yes.

Is y [still] an object if the C compiler optimizes it away

I'm talking about the C language, not any compiler. From
the perspective of the language, 'y' is an object, created
by the statement which defines it. What an implementation
does with it doesn't matter.

and computes

int z = 3*(x + 1);

directly?

The statement:

int y = x + 1;

Creates an object (with or without the initializer).

-Mike

 

[Mike Wahler]

I suppose that it also depends upon the code.


This appears to be consistent with my assertion that
"and object is a value that *could* occupy storage.

No. No. No. An object is *not* a value. As a matter of fact,
an object can exist which does not represent a value.

int main()
{
int i; /* an object with no value */

return 0;
}

int x = 42;

How does the "abstract machine" know that
x is initialized with the value 42?

Because the source code stated so in a way compliant
with the language definition.

A C program is correspondence from the programmer to the C compiler
and not any underlying abstract [or concrete] machine.

No. The communication is from the coder to the abstract machine.
The C language's existence does not depend upon the existence
of any implementations. (though its usefulness does).

According to Brian W. Kernighan and Dennis M. Ritchie,

The rest is such blatant trolling, I'll just delete it.

-Mike

 

[Irrwahn Grausewitz]

Amongst other crap

"E. Robert Tisdale" <[email protected]> wrongly asserted:

No. No. No. An object is *not* a value. As a matter of fact,
an object can exist which does not represent a value.

Agreed: an object is not a value, it's a region of storage that /can/
hold a value, but /may/ hold a bit pattern that does not represent a
valid value with respect to the type of the object.

int main()
{
int i; /* an object with no value */

But I'm not sure this comment is entirely correct from a pedant's
point of view: the standard postulates that the value is
indeterminate. An indeterminate value is defined as "either an
unspecified value or a trap representation" (C99 3.17.2). The
uninitialized object designated by i might actually hold a value;
alas, one cannot check without invoking undefined behaviour.

Not that it really matters, practically.

Regards

 

[Arthur J. O'Dwyer]

"Mike Wahler" <[email protected]> correctly replied: [inside a function]

int i; /* an object with no value */

But I'm not sure this comment is entirely correct from a pedant's
point of view: the standard postulates that the value is
indeterminate. An indeterminate value is defined as "either an
unspecified value or a trap representation" (C99 3.17.2). The
uninitialized object designated by i might actually hold a value;
alas, one cannot check without invoking undefined behaviour.

So by the as-if rule, it is correct both that "i has no value"
*and* that "i has a value." ;-) Nice attribution line [snipped],
BTW. ;-))

And another reminder to people not to feed the trolls once their
errors have been satisfactorily rebuffed already in one thread.
Thanks.

-Arthur

 

[Richard Bos]

But you need to know whether you are sending one gas bill (to the detached
house) or many (to each resident of the block of flats).

You already do; you've either written one bill or many. Post as many
bills as you have to as many addresses.
IOW: you either do an operation on a block of memory or on a single
object. You need to know whether you can have several objects or not
when you design the algorithm, not just when your running program first
sees the pointer.

If "int *ptr;" were a pointer to an integer, period,

Nobody said it was. It's an object of type "pointer to int". That is, it
points to an int object, or possibly to several. It does not point to an
entire array. It _may_ point to one of the array's members, possibly the
first one, but it does not point to the entire array at once.

Richard

 

[Andy Green]

Unfortunately many educational institutions disagree. I dropped my CS major
because of this, actually; the entire undergrad program was dedicated to
teaching me things I already knew or could have picked up on my own, and all
the classes I wanted to take to learn REAL computer science were
post-graduate level.


I've always considered "sciences" to be about building on existing ideas to
create and validate (or invalidate) new ideas, whereas "engineering" is more
an application of existing ideas to real-world problems. In programming
this is a bit blurred, but one can surely see the distinction between trying
to find new compiler optimizations vs. coding some commercial database app.


I'd say that software design requires a very different skillset than
software implementation, but both are aspects of software engineering.

S

I am no expert. But I know that an when you declare an array, that
array is an address that starts somewhere in memory and is reserved
for physical storage stof elements. The first element starts at the
address. A pointer, is just an element that stores an adress and that
is it, it is like a variable but it contains an address. So what is so
complicated?. What am I missing?

 

[Dan Pop]

I am no expert. But I know that an when you declare an array, that
array is an address that starts somewhere in memory and is reserved
for physical storage stof elements. The first element starts at the
address. A pointer, is just an element that stores an adress and that
is it, it is like a variable but it contains an address. So what is so
complicated?. What am I missing?

Two things:

sizeof array
&array

The name of the array doesn't refer to any address, it refers to the
object itself. However, in most contexts, references to arrays are
automatically *converted* to pointers to their first elements. The
exceptions are listed above: sizeof array gives the size of the whole
array and not the size of a pointer to its first element and &array is
a pointer to the whole array, not to the first element of the array
(this is a change from K&R C), which is relevant in pointer contexts,
even if the address of the whole array coincides with the address of
its first element.

Dan