Re: Address of an array = address of its 1st element: undecidable question ?

[Ben Bacarisse]

candide <to**@free.frwrites:

I try to find out what exactly means "an array and its address are the
same" or "have the same value".

These two statements are very different. The first one is just wrong
and I am pretty sure you did not mean to suggest that. There is no
object in C that is the same as its address.

The second one simply depends on a term that is not well-defined.

Most people consider the type to be an important part of the notion of
value, so two things of different type are not likely to be considered
the same. They may compare equal (0 == 0.0 in C) but that is not the
same. (In other languages one type can be included in another so two
values may be exactly the same even in they have different types but
that is not really the way C types work.)

Of course, people can be lax with words. I may say, off hand, that 0
and 0.0 have the same value and that is a perfectly defensible
statement but only if you know the ways in which they differ. It is
equally valid to say that they are *not* the same value. What matters
is not the answer to an ill defined question but a full understanding
of arrays, pointers, and their relationships.

Everybody seems to agree that they doesn't share the same type, of
course.

Good. That is indisputable.

For enlighting the discussion, here some more or less contradictory
quotes from clc and comp.std.c regarding this question :

-------------------------------- 8<
-------------------------------------------
On 29 juin 2004, 06:06, [e-mail] wrote:

>I'm not aware of any definition (or even description) of the C language
that said that taking theaddressof anarraywas equivalent to taking
theaddressof the first member of thearray. Certainly there were
compilers that worked that way, but there were also many compilers that
considered it an error and didn't allow it at all.

This one is taken out of context. IIRC LJ was taking about historical
C compilers before the construct of taking the address of an array had
been defined by the language standard.

On 31 déc 1996, 10:00, [e-mail] (Lawrence Kirby) wrote:

>(...) The address of an array IS the address of
it's first element.

The standard doesn't say so explicitly although a conforming

implementation

>doesn't really have much choice in the matter. (void *)&s and (void

*)&s[0]

>pretty much have to generate thesameaddress or else standard library
functions like fread() would have problems.

OK, I have no problem with that. The way in which the values are "the
same" is made explicit -- they compare equal when converted to void*.

On 7 mai 1999, 09:00, Dennis Ritchie <[e-mail]:

>Paul Seale wrote:

OK, but what IS the address of an array? If we consider that in most
contexts an array name "a" is converted to &a[0], then the closest

thing I

can imagine that would be anarray addressis the address of a cell that
holds &a[0]. Seems like that is just creating an unnecessary level of
indirection. I'd be interested in an example where this would be

useful.

>>
In the usual implementation the bit value of &a[0] and &a will be the
same,
but the type is different (ptr to int, ptr to array of int).
If you add 1 to them you will get different answers.

OK. Again, I see no problem. Note the DR is careful to say "the bit
value". He does not really care about the bits, he wants a phrase
that means "the value when you have thrown away or ignored the type".
Bit value is a good way to suggest that.

On 25 fév 1996, 10:00, [e-mail] (Kazimir Kylheku) wrote:

>Don't be fooled by the fact that the above works. It just so happens

that

>myarray and &myarray are both expressions that yield the same

pointer. But the

>two pointers have a different type.

Again, no contradiction. KK is explicit that the pointers have
different types so he must be using "the same" to mean "the same
except for the type". If KK had just said "... yield the same
pointer" and stopped there, someone would have come in to clarify the
matter. The term "the same" is just too vague to left unqualified.

On 19 sep 2006, 21:51, Keith Thompson <[e-mail]:
[...]

>&array is a perfectly legitimate expression; it yields the address of
the array, which is distict from the address of itsfirstelement.
They have the "same value" in some sense, but they're of different
types.

KT prefers to emphasise the difference and puts "the same" in quotes to
show that it is vague and need qualification. No contradiction that
I can see.

On 11 fév 2008, 19:47, [e-mail] wrote:

>[...] The address of an array is the same as
the address of its first element just as the address of a struct is the
same as the address of its first member (the addresses are the same but
the types are different)

More of the same. The problem is entirely due to how the writer like
to view the phrase "the same". LJ obviously prefers to emphasise the
similarity but he, too, is careful to point out the difference.

On 7 mai 1999, 09:00, Larry Jones <[e-mail]:

>Paul Seale wrote:

OK, but what IS theaddressof anarray?

What's theaddressof a struct? Theaddressof a struct is "the same
as" theaddressof its first member, but they have different types.
Likewise, theaddressof anarrayis "the same as" theaddressof its
first element, but they have different types. (By "the same as", I
mean that they compare equal if you convert them both to (void *)).

Again, another careful writer putting the matter quite clearly in my
view. The "scare quotes" draw attention to the problem phrase but
both the similarities and the differences are made explicit.

So what ? Is the question undecidable ?

If you include the notion of type in that of value, then the answer is
"no". If you don't then the answer can be a qualified "yes". The
qualification is made very clear by most of the quotes ("the bit
values are the same", "they compare equal when converted to void *")
but even when it is glossed over, there is no contradiction.

My personal preference is to be strict about the types so I would say
that the values are not the same if I have to make just one statement
about them. If you were to permit me, I'd go on to say that they have
values that convert to equal void *s. The C standard is very clear
that a pointer to a whole object and pointer to one of its initial
sub-objects must compare equal (provided you convert the pointers so
that comparison is permitted) so the pointers have the same value in
that limited sense.

--
Ben.

[ymuntyan]

On May 22, 9:00*pm, Ben Bacarisse <[e-mail]:

candide <[e-mail]:

I try to find out what exactly means "an array and its address are the
same" or "have the same value".

These two statements are very different. *The first one is just wrong
and I am pretty sure you did not mean to suggest that. *There is no
object in C that is the same as its address.

The second one simply depends on a term that is not well-defined.

How about using the standard definition? Then all is good and
clear, answer is "no and the question doesn't make much sense".
Making up the meaning of "value of array" is silly otherwise.
(True, it's an interesting philosophical exercise, like whether
the element of one-element array is the array or not... And it
certainly is on-topic and so is "interesting and useful"!)

[snip long list of who (Ritchie included!) says what]

Yevgen

[Ben Bacarisse]

ym******@gmail.com writes:

On May 22, 9:00Â*pm, Ben Bacarisse <[e-mail]:

>candide <[e-mail]:

I try to find out what exactly means "an array and its address are the
same" or "have the same value".

These two statements are very different. Â*The first one is just wrong
and I am pretty sure you did not mean to suggest that. Â*There is no
object in C that is the same as its address.

The second one simply depends on a term that is not well-defined.

How about using the standard definition?

I am not sure exactly what you mean. I don't think the term "same
value" is used clearly and unambiguously thought the standard. At
least, I don't think it is used in way that can be understood without
context.

Then all is good and
clear, answer is "no and the question doesn't make much sense".
Making up the meaning of "value of array" is silly otherwise.

The value of an array has a reasonable meaning in C. You can't so
much with them, but that is beside the point. I don't think I made up
a meaning for it.

(True, it's an interesting philosophical exercise, like whether
the element of one-element array is the array or not... And it
certainly is on-topic and so is "interesting and useful"!)

[snip long list of who (Ritchie included!) says what]

I thought my answer was helpful because, rather than taking a
definitive view on the meaning of the words, it explained why the
various phrases quoted are all consistent provided one does not assume
that slightly ambiguous terms can be pinned down one way or the other.
Most of the quotes went to some lengths to explain why the two values
in question were the same in some sense and different in others.
Plumping for one or the other if fine (I said as much) but not as
helpful as I was trying to be. Of course, I may have missed by a mile
and just confused the OP. Only time will tell.

--
Ben.

[Keith Thompson]

Ben Bacarisse <be********@bsb.me.ukwrites:

ym******@gmail.com writes:

>On May 22, 9:00*pm, Ben Bacarisse <[e-mail]:

>>candide <[e-mail]:
I try to find out what exactly means "an array and its address are the
same" or "have the same value".

These two statements are very different. *The first one is just wrong
and I am pretty sure you did not mean to suggest that. *There is no
object in C that is the same as its address.

The second one simply depends on a term that is not well-defined.

How about using the standard definition?

I am not sure exactly what you mean. I don't think the term "same
value" is used clearly and unambiguously thought the standard. At
least, I don't think it is used in way that can be understood without
context.

Ah, but the standard does define the term "value", in C99 3.17:

value
precise meaning of the contents of an object when interpreted as
having a specific type

Given this definition, it doesn't make much sense to say that objects
of different types can have the "same value".

(One flaw in this definition is that it doesn't define the value of an
expression.)

>Then all is good and
clear, answer is "no and the question doesn't make much sense".
Making up the meaning of "value of array" is silly otherwise.

The value of an array has a reasonable meaning in C. You can't so
much with them, but that is beside the point. I don't think I made up
a meaning for it.

Agreed; given the standard's definition of "value" the value of an
array is a fairly obvious concept.

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Bacarisse]

Keith Thompson <ks***@mib.orgwrites:

Ben Bacarisse <be********@bsb.me.ukwrites:

>ym******@gmail.com writes:

>>On May 22, 9:00Â*pm, Ben Bacarisse <[e-mail]:
candide <[e-mail]:
I try to find out what exactly means "an array and its address are the
same" or "have the same value".

These two statements are very different. Â*The first one is just wrong
and I am pretty sure you did not mean to suggest that. Â*There is no
object in C that is the same as its address.

The second one simply depends on a term that is not well-defined.

How about using the standard definition?

I am not sure exactly what you mean. I don't think the term "same
value" is used clearly and unambiguously thought the standard. At
least, I don't think it is used in way that can be understood without
context.

Ah, but the standard does define the term "value", in C99 3.17:

value
precise meaning of the contents of an object when interpreted as
having a specific type

Given this definition, it doesn't make much sense to say that objects
of different types can have the "same value".

(One flaw in this definition is that it doesn't define the value of an
expression.)

To my mind, this is a fatal flaw for this discussion. The question is
all about expressions and not the values of objects.

--
Ben.

[Yevgen Muntyan]

Ben Bacarisse wrote:

ym******@gmail.com writes:

>On May 22, 9:00 pm, Ben Bacarisse <[e-mail]:

>>candide <[e-mail]:
I try to find out what exactly means "an array and its address are the
same" or "have the same value".
These two statements are very different. The first one is just wrong
and I am pretty sure you did not mean to suggest that. There is no
object in C that is the same as its address.

The second one simply depends on a term that is not well-defined.

How about using the standard definition?

I am not sure exactly what you mean.

I mean the definition of the term "value of an object"
from the standard.

I don't think the term "same
value" is used clearly and unambiguously thought the standard. At
least, I don't think it is used in way that can be understood without
context.

Could you provide an example perhaps? Really, once
you don't think that a "value of an array" can mean
value of the pointer it's converted to (namely, of
the result of the corresponding expression, or
whatever it is in legalese), then you don't have
any problems with the term "value" and its use in
a phrase "same value". I guess the problem is that
the standard uses human language in this case ;)

>

>Then all is good and
clear, answer is "no and the question doesn't make much sense".
Making up the meaning of "value of array" is silly otherwise.

The value of an array has a reasonable meaning in C. You can't so
much with them, but that is beside the point. I don't think I made up
a meaning for it.

>(True, it's an interesting philosophical exercise, like whether
the element of one-element array is the array or not... And it
certainly is on-topic and so is "interesting and useful"!)

[snip long list of who (Ritchie included!) says what]

I thought my answer was helpful because, rather than taking a
definitive view on the meaning of the words, it explained why the
various phrases quoted are all consistent provided one does not assume
that slightly ambiguous terms can be pinned down one way or the other.
Most of the quotes went to some lengths to explain why the two values
in question were the same in some sense and different in others.
Plumping for one or the other if fine (I said as much) but not as
helpful as I was trying to be. Of course, I may have missed by a mile
and just confused the OP. Only time will tell.

Nah, I don't think the explanation hurt someone. It's
the question that is silly. Discussing array-related
stuff isn't bad for sure.

Yevgen

[Keith Thompson]

Ben Bacarisse <be********@bsb.me.ukwrites:

Keith Thompson <ks***@mib.orgwrites:

>Ben Bacarisse <be********@bsb.me.ukwrites:

>>ym******@gmail.com writes:

On May 22, 9:00*pm, Ben Bacarisse <[e-mail]:
candide <[e-mail]:
I try to find out what exactly means "an array and its address are the
same" or "have the same value".
>
These two statements are very different. *The first one is just wrong
and I am pretty sure you did not mean to suggest that. *There is no
object in C that is the same as its address.
>
The second one simply depends on a term that is not well-defined.

How about using the standard definition?

I am not sure exactly what you mean. I don't think the term "same
value" is used clearly and unambiguously thought the standard. At
least, I don't think it is used in way that can be understood without
context.

Ah, but the standard does define the term "value", in C99 3.17:

value
precise meaning of the contents of an object when interpreted as
having a specific type

Given this definition, it doesn't make much sense to say that objects
of different types can have the "same value".

(One flaw in this definition is that it doesn't define the value of an
expression.)

To my mind, this is a fatal flaw for this discussion. The question is
all about expressions and not the values of objects.

It's a minor flaw in the definition of "value". (It's not the only
definition in the standard that provides an example of the term being
defined rather than an exhaustive definition). It's clear that
expressions do have values; see the standard's (also incomplete)
definition if "expression" in 6.5p1:

An _expression_ is a sequence of operators and operands that
specifies computation of a value, or that designates an object or
a function, or that generates side effects, or that performs a
combination thereof.

I think it's sufficiently clear for purposes of this discussion that a
"value", whether it's contained in an object or results from
evaluating an expression, has a specific type. I don't think it's
possible to discuss this stuff consistently without making that
assumption.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Bacarisse]

Keith Thompson <ks***@mib.orgwrites:

Ben Bacarisse <be********@bsb.me.ukwrites:

>Keith Thompson <ks***@mib.orgwrites:

>>Ben Bacarisse <be********@bsb.me.ukwrites:
ym******@gmail.com writes:

On May 22, 9:00Â*pm, Ben Bacarisse <[e-mail]:
>candide <[e-mail]:
I try to find out what exactly means "an array and its address are the
same" or "have the same value".
>>
>These two statements are very different. Â*The first one is just wrong
>and I am pretty sure you did not mean to suggest that. Â*There is no
>object in C that is the same as its address.
>>
>The second one simply depends on a term that is not well-defined.
>
How about using the standard definition?

I am not sure exactly what you mean. I don't think the term "same
value" is used clearly and unambiguously thought the standard. At
least, I don't think it is used in way that can be understood without
context.

Ah, but the standard does define the term "value", in C99 3.17:

value
precise meaning of the contents of an object when interpreted as
having a specific type

Given this definition, it doesn't make much sense to say that objects
of different types can have the "same value".

(One flaw in this definition is that it doesn't define the value of an
expression.)

To my mind, this is a fatal flaw for this discussion. The question is
all about expressions and not the values of objects.

It's a minor flaw in the definition of "value".

OK. I can see how /you/ see it that way but as a definition to be used
to explain (to someone learning all this) the flaw is a little more
than minor -- it is a definition that does not apply. Neither
expression in question is (or designates) an object so there are no
contents to be interpreted.

Of course it can be fixed (but see below) but I think the fact that it
has to be extended and qualified is more than a minor flaw. "Fatal
flaw" was probably too strong. If you want to stick with "minor", in
the context of someone learning C, than I won't press the matter but I
will beg to differ.

(It's not the only
definition in the standard that provides an example of the term being
defined rather than an exhaustive definition).

<aside>
Continuing your aside, I think the problem of the definition is a
little deeper than that. With the above definition, in mind some
phrases just seem daft:

"The meaning of a value stored in an object or returned by a
function is determined by the type of the expression used to access
it."

This is obviously intended to reinforce the definition and should
probably have been something like "The precise meaning of the data
stored in an object or returned by a function is determined by the
type of the expression used to access it. This is called the value of
the object or function." I say "probably" because I may have missed
the intent. What is clear is that one should not talk about the
meaning of a value if a values is defined as the precise meaning of
something else.

Then there is this:

"A constant is a primary expression. Its type depends on its form
and value, as detailed in 6.4.4."

That is circular since its value depends on the type. Of course, the
circularity can be broken by "trying" the different types in section
6.4.4 but even that is complicated because 6.4.4 says:

"The type of an integer constant is the first of the corresponding
list in which its value can be represented."

and earlier:

"Each constant shall have a type and the value of a constant shall be
in the range of representable values for its type."

It is much easier to resolve these three if we take "value" to have the
looser mathematical meaning.

Finally, the standard talks about "copying values". I don't see how
values in the sense of "precise meanings..." can be copied. I think
the standard does not take its own definition of value too seriously.
</aside>

It's clear that
expressions do have values; see the standard's (also incomplete)
definition if "expression" in 6.5p1:

An _expression_ is a sequence of operators and operands that
specifies computation of a value, or that designates an object or
a function, or that generates side effects, or that performs a
combination thereof.

I think it's sufficiently clear for purposes of this discussion that a
"value", whether it's contained in an object or results from
evaluating an expression, has a specific type. I don't think it's
possible to discuss this stuff consistently without making that
assumption.

I agree, but I don't think the standard's definition makes that
clear. It suggests that objects (and by your extension the results of
expressions) have a value only "when" interpreted. Of course, at every
point in a program, every object and expression has some effective
type which is the one used to "induce" the value, but I would prefer
that the linkage be explicit in the definition.

I think it is much simpler to view types as set of values. Objects
contain representations of values, and expressions (by dint of having
a value) have a type (the set of which the result is a member). Then,
questions about values being the same or not would be determined by the
mathematical structure of the types -- some languages use disjoint
unions so that 1 and 1.0 are not "the same value" while in others the
representable integers are stated to be a subset of the representable
floats. Of course, I have no idea if the language of the standard
could be re-cast in this form.

--
Ben.

[Ben Bacarisse]

Yevgen Muntyan <mu*****@removethis.tamu.eduwrites:

Ben Bacarisse wrote:

>ym******@gmail.com writes:

>>On May 22, 9:00 pm, Ben Bacarisse <[e-mail]:
candide <[e-mail]:
I try to find out what exactly means "an array and its address are the
same" or "have the same value".
These two statements are very different. The first one is just wrong
and I am pretty sure you did not mean to suggest that. There is no
object in C that is the same as its address.

The second one simply depends on a term that is not well-defined.
How about using the standard definition?

I am not sure exactly what you mean.

I mean the definition of the term "value of an object"
from the standard.

OK. Yes one could certainly use that definition. I don't think it is
without it problems. I've detailed some of these problems in a reply
to Keith Thompson elsewhere but despite these it is workable. In this
context, the main reason I would not cite it is that is does not
apply, since it talks about objects and neither expression in question
was an object.

I see that the discussion of that has already moved on, so this point
is probably moot, but my real objection to using it is that is does
not help answer the question that the OP had. The OP was confused by
people using phrases like "bit value" and "the addresses are the
same". Explaining what these terms meant and the ways in which they are
consistent with, for example, Keith Thompson's more formal quote
seemed more helpful.

>I don't think the term "same
value" is used clearly and unambiguously thought the standard. At
least, I don't think it is used in way that can be understood without
context.

Could you provide an example perhaps?

I've given some in my other answer. It is not specifically the phrase
"same value" that is problem it is just that the standard does not
seem convinced by its own definition.

Really, once
you don't think that a "value of an array" can mean
value of the pointer it's converted to (namely, of
the result of the corresponding expression, or
whatever it is in legalese), then you don't have
any problems with the term "value" and its use in
a phrase "same value".

Yes, I though that was clear in my answer. I am sorry if it was not.

--
Ben.

[Ben Bacarisse]

candide <to**@free.frwrites:

Ben Bacarisse wrote:

>If you include the notion of type in that of value, then the answer is
"no". If you don't then the answer can be a qualified "yes". The
qualification is made very clear by most of the quotes ("the bit
values are the same", "they compare equal when converted to void *")
but even when it is glossed over, there is no contradiction.

The contradiction I referred to was the first quote from Larry Jones but
this is not my point.

Sorry, I don't see the contradiction. I though the historical
reference had misled you. Let me pay more attention to the quote,
then. He says:

| I'm not aware of any definition (or even description) of the C language
| that said that taking the address of an array was equivalent to taking
| the address of the first member of the array.

What does "equivalent to" mean? I don't know for sure, but since the
two operations produce different types it seems a stretch to say he is
at odds with any of the other writers. The current standard says that
when suitable converted they will compare equal, but I am sure he know
that!

About the wording "the bit values are the same", did you notice that
DMR was suggesting that the bit value coincidence was not a portable
property, for being restricted to the "usual implementation" as he
said himself ?

Yes I did.

By the way, what exactly is the "usual implementation"
?

Presumably he means when the address space is "flat". A segmented
architecture could produce different bit values, maybe, which is fine
provided that they compare equal using == after conversion. On such a
system, after

int data[10];
int *ip = &data[0]; /* or just = data, of course */
int (*ap)[10] = &data;

we could have memcmp(&ip, &ap, sizeof ip) != 0 provided that
(void *)ip == (void *)ap.

If you really must know exactly he means, you'll have to ask him, but
do you think was saying something that was at odds with accepted
wisdom?

And what is exactly meant by "the bit values are the same" ?

I would take it to mean what you get when viewing a stored value as an
array of bytes (an unsigned char [n]). The memcmp example is a short
hand. We could write out:

unsigned char ipbv[sizeof ip];
unsigned char apbv[sizeof ap];
memcpy(ipbv, &ip, sizeof ipbv);
memcpy(apbv, &ap, sizeof apbv);
/* and not test: */
sizeof ipbv == sizeof apbv && memcmp(ipbv, apbv, sizeof ipbv) == 0

but that is just too long-winded.

Does this
mean that my_array and &my_array yield the same bit representation ?

No. It means he thinks they would using the "usual implementation".
You then can either say his idea of usual is wrong or use it to find
out what he thinks of as usual. Your choice.

If so, does the standard guarantee such a thing ? I don't think so :

-------------------- 8< -----------------------------
§6.2.5
All pointers to structure types shall have the same representation and
alignment requirements as each other. All pointers to union types
shall have the same representation and alignment requirements as each
other.
Pointers to other types need not have the same representation or
alignment requirements.
-------------------- >8 -----------------------------

Absolutely. This tells me what DR thinks is usual, not that he is wrong.

Larry Jones put on the same level the correspondance between an array
address vs its first member address and the analog correspondance for
structures.
Why does the Standard take care of the structure case and even
doesn't mention the array case ? I recall the Standard says :

-------------------- 8< -----------------------------
§6.7.2.1
A pointer to a structure object, suitably converted, points to its
initial member (...) and vice versa.
-------------------- >8 -----------------------------

How does one adapt this situation to the array case ? For instance,
declaring

int t[3];

can we expect (int *)&t will always equal to &t[0] ? and conservely, &t
will equal to (int (*)[3])&t[0] ?

Yes, I think so. See the definition of ==.

>about them. If you were to permit me, I'd go on to say that they have
values that convert to equal void *s. The C standard is very clear
that a pointer to a whole object and pointer to one of its initial
sub-objects must compare equal (provided you convert the pointers so
that comparison is permitted) so the pointers have the same value in
that limited sense.

I suppose you are referring to the following excerpt of the Standard
:

-------------------- 8< -----------------------------
Two pointers compare equal if and only if both are null pointers, both
are pointers to the same object (including a pointer to an object and
a subobject at its beginning) or function, [...]
-------------------- >8 -----------------------------

Ah. I see you already have that in mind.

The Standard doesn't define what is meant by a subobject. I can
imagine that an array element is a subobject of the whole array. But
how on earth pointers to object that doesn't share the same type can
compare equal ?

They can if the types are compatible. I am not really sure anymore
what your point is. Do you disagree that, suitable converted, a
pointer to an array and a pointer to the first element of an array
will compare equal? If so, I think you are wrong. If you think
someone has said they won't, then who?

It is worth mentionning that the last quote above is not exactly the
same as in the C90 standard wich omits the reference to the case of a
subobject :

-------------------- 8< -----------------------------
If two pointers to object or incomplete types compare equal, they
point to the same object. If two pointers to functions compare [...]
-------------------- >8 -----------------------------

I suspect the addition was deliberate.

--
Ben.

[Yevgen Muntyan]

James Kuyper wrote:

Ben Bacarisse wrote:

>candide <to**@free.frwrites:

>>Ben Bacarisse wrote:

...

>| I'm not aware of any definition (or even description) of the C language
| that said that taking the address of an array was equivalent to taking
| the address of the first member of the array.

What does "equivalent to" mean? I don't know for sure, but since the
two operations produce different types it seems a stretch to say he is
at odds with any of the other writers. The current standard says that
when suitable converted they will compare equal, but I am sure he know
that!

Citation please?

There is wording to that effect in 6.7.2.1p13 with respect to structures
and their first member, but I couldn't find comparable wording about
arrays and their first element; by analogy with structures, I'd expect
such wording to be in section 6.7.5.2; I couldn't find it there, or
anywhere else that I looked.

On May 24, 11:28 am, James Kuyper <[e-mail]:

Ben Bacarisse wrote:

candide <[e-mail]:

Ben Bacarisse wrote:

...

| I'm not aware of any definition (or even description) of the C

language

| that said that taking the address of an array was equivalent to

taking

| the address of the first member of the array.

What does "equivalent to" mean? I don't know for sure, but since the
two operations produce different types it seems a stretch to say he is
at odds with any of the other writers. The current standard says that
when suitable converted they will compare equal, but I am sure he know
that!

Citation please?

There is wording to that effect in 6.7.2.1p13 with respect to structures
and their first member, but I couldn't find comparable wording about
arrays and their first element; by analogy with structures, I'd expect
such wording to be in section 6.7.5.2; I couldn't find it there, or
anywhere else that I looked.

It's not needed, because by definition of array its first byte
is the first byte of its first element. So, after *suitable*
conversion (e.g. to unsigned char*), the pointers will compare
equal, guaranteed (6.2.5p20, 6.3.2.3p7). Whether you can do

int a[3];
int *p = (int*)&a;
int ba = *p;

is another question (my guess is it's undefined, though
perhaps aliasing rules do allow this, but I don't care
anyway).

Structures are different because they may have holes and
so they need 1) explicit guarantee that there is no padding
at the beginning, and they need 2) explicit permission
for the pointer conversion because we want this conversion,
while nobody ever casts a pointer to an array to pointer
to its first element.

Yevgen

[James Kuyper]

On May 24, 11:28 am, James Kuyper <[e-mail]:

Ben Bacarisse wrote:

candide <[e-mail]:

>

Ben Bacarisse wrote:

...

| I'm not aware of any definition (or even description) of the C

language

| that said that taking the address of an array was equivalent to

taking

| the address of the first member of the array.

>

What does "equivalent to" mean? I don't know for sure, but since the
two operations produce different types it seems a stretch to say he is
at odds with any of the other writers. The current standard says that
when suitable converted they will compare equal, but I am sure he know
that!

>
Citation please?
>
There is wording to that effect in 6.7.2.1p13 with respect to structures
and their first member, but I couldn't find comparable wording about
arrays and their first element; by analogy with structures, I'd expect
such wording to be in section 6.7.5.2; I couldn't find it there, or
anywhere else that I looked.

It's not needed, because by definition of array its first byte
is the first byte of its first element. So, after *suitable*
conversion (e.g. to unsigned char*), the pointers will compare
equal, guaranteed (6.2.5p20, 6.3.2.3p7). Whether you can do

Given

T array[N];

Where T represents any particular object type, I agree that 6.3.2.3p7
guarantees that (char*)array == (char*)array[0]. I don't see that
there's anything with says that (T*)&array == &array[0], except when T
is a character type.

int a[3];
int *p = (int*)&a;
int ba = *p;

is another question (my guess is it's undefined, though
perhaps aliasing rules do allow this, but I don't care
anyway).

The standard fails to specify where p points; but I think it was clearly
the intent that p points at a[0]. If so, then assuming that 'a' gets
initialize before the evaluation of *p, ba should end up holding the
same value as a[0].

[Ben Bacarisse]

James Kuyper <ja*********@verizon.netwrites:

Ben Bacarisse wrote:

>candide <to**@free.frwrites:

>>Ben Bacarisse wrote:

...

>| I'm not aware of any definition (or even description) of the C language
| that said that taking the address of an array was equivalent to taking
| the address of the first member of the array.

What does "equivalent to" mean? I don't know for sure, but since the
two operations produce different types it seems a stretch to say he is
at odds with any of the other writers. The current standard says that
when suitable converted they will compare equal, but I am sure he know
that!

Citation please?

Already given (I am slow today) but I would add that there is another
conversion that I think meets my wording of "suitable". Given:

T array[N];

I think &array == (int (*)[])array is also guaranteed.

--
Ben.

[James Kuyper]

Ben Bacarisse wrote:

James Kuyper <ja*********@verizon.netwrites:

>Ben Bacarisse wrote:

>>candide <to**@free.frwrites:

Ben Bacarisse wrote:

...

>>| I'm not aware of any definition (or even description) of the C language
| that said that taking the address of an array was equivalent to taking
| the address of the first member of the array.

What does "equivalent to" mean? I don't know for sure, but since the
two operations produce different types it seems a stretch to say he is
at odds with any of the other writers. The current standard says that
when suitable converted they will compare equal, but I am sure he know
that!

Citation please?

Already given (I am slow today) ...

I haven't seen a relevant citation yet; I've explained why I felt that
Yevgen's citation wasn't relevant. Do you have response to my objections?
....

but I would add that there is another
conversion that I think meets my wording of "suitable". Given:

T array[N];

I think &array == (int (*)[])array is also guaranteed.

Only if T is a typedef for 'int'.

[Ben Bacarisse]

James Kuyper <ja*********@verizon.netwrites:

Ben Bacarisse wrote:

>James Kuyper <ja*********@verizon.netwrites:

>>Ben Bacarisse wrote:
candide <to**@free.frwrites:

Ben Bacarisse wrote:
...
| I'm not aware of any definition (or even description) of the C language
| that said that taking the address of an array was equivalent to taking
| the address of the first member of the array.

What does "equivalent to" mean? I don't know for sure, but since the
two operations produce different types it seems a stretch to say he is
at odds with any of the other writers. The current standard says that
when suitable converted they will compare equal, but I am sure he know
that!
Citation please?

Already given (I am slow today) ...

I haven't seen a relevant citation yet; I've explained why I felt that
Yevgen's citation wasn't relevant.

We must have crossed wires. My citation is 6.3.2.3p7 requiring the
pointers to compare equal when "suitably converted" (to a pointer to a
character type). I thought you'd agreed with that elsewhere.

Do you have response to my objections?

Do you mean that (T *)&array might not point to the first sub-object
of a T array? No, I don't. I would have an objection to an
implementation that did something that odd, but I think it is
permitted.

The easiest way for "C on the DS9000" to do this is to make
(T *)&array badly aligned for a T object. That is permitted and just
constructing the pointer is UB (same citation). I don't think there
is any need for it to make (T *)&array point to some element other
than the first.

...

>but I would add that there is another
conversion that I think meets my wording of "suitable". Given:

T array[N];
I think &array == (int (*)[])array is also guaranteed.

Only if T is a typedef for 'int'.

Rats! But I presume you got the idea: that there was another
"suitable" conversion not yet given in the thread. Of course I
intended to type: "&array == (T (*)[])array".

--
Ben.

[James Kuyper]

Ben Bacarisse wrote:

James Kuyper <ja*********@verizon.netwrites:

>Ben Bacarisse wrote:

>>James Kuyper <ja*********@verizon.netwrites:

Ben Bacarisse wrote:
candide <to**@free.frwrites:
>
>Ben Bacarisse wrote:
...
| I'm not aware of any definition (or even description) of the C language
| that said that taking the address of an array was equivalent to taking
| the address of the first member of the array.
>
What does "equivalent to" mean? I don't know for sure, but since the
two operations produce different types it seems a stretch to say he is
at odds with any of the other writers. The current standard says that
when suitable converted they will compare equal, but I am sure he know
that!
Citation please?
Already given (I am slow today) ...

I haven't seen a relevant citation yet; I've explained why I felt that
Yevgen's citation wasn't relevant.

We must have crossed wires. My citation is 6.3.2.3p7 requiring the
pointers to compare equal when "suitably converted" (to a pointer to a
character type). I thought you'd agreed with that elsewhere.

I thought you were referring to converting one pointer to the other
pointer's type. That is how I interpret the only case where the standard
actually uses the phrase "suitably converted" (6.7.2.1p13). If you are
talking about converting both pointers into character type pointers,
then I agree that it is covered by 6.3.2.3p7.

>Do you have response to my objections?

Do you mean that (T *)&array might not point to the first sub-object
of a T array? No, I don't. I would have an objection to an
implementation that did something that odd, but I think it is
permitted.

The easiest way for "C on the DS9000" to do this is to make
(T *)&array badly aligned for a T object. ...

I don't think it was the intent of the committee to allow for it to be
misaligned. I think that, if that is allowed, it is a result of an error
in the wording of the standard, not something that was deliberately
allowed for.

... That is permitted and just
constructing the pointer is UB (same citation). I don't think there
is any need for it to make (T *)&array point to some element other
than the first.

There is no reason I can think of why any implementation should do
anything with a permitted pointer conversion other than producing a
pointer of the new type that points at the same location in memory as
the original pointer. I doubt that there are any implementations that do
anything different from that. I think there's a huge amount of code
based upon the assumption that this is the way pointer conversions work.
It bothers me that the standard falls short of actually guaranteeing
that this is the way pointer conversions work.

[Ben Bacarisse]

candide <to**@free.frwrites:

Ben Bacarisse wrote:

>(...) I am not really sure anymore
what your point is. Do you disagree that, suitable converted, a
pointer to an array and a pointer to the first element of an array
will compare equal?

This is exactly my point (and BTW, what do you mean by "suitably
converted" ?).

Well that is clear then. By "suitably converted" I just meant
converted so that the statement is true. In other words it was a way
of saying that there is are conversions that make it true without
having to say what. It was deliberately vague because exactly what is
guaranteed buy the standard and what is simply a reasonable
interpretation of it is not 100% clear. Given

T array[N];

I am sure that (char *)&array == (char *)array is guaranteed by
section 6.3.2.3 paragraph 7.

I think only the most deliberately contrived interpretation of the
standard would not extend the guarantee to both (void *)&array ==
(void *)array and to &array == (T (*)[])array. I consider all of the
above suitable for the purposes of my quote.

I think the intent is that (T *)&array == array but there are enough
gaps in the wording that it can't be guaranteed to the satisfaction of
all.

>If so, I think you are wrong. If you think
someone has said they won't, then who?

Nobody said so. But some refrained from answering the question.

Well, no one is obliged to answer anything. I hope it is all clear
now! It is of very little practical value since there is an obvious
and guaranteed way to get a pointer to any element of an array.

--
Ben.

[lawrence.jones]

There's been lots of discussion about the following quote from me:

| I'm not aware of any definition (or even description) of the C language
| that said that taking the address of an array was equivalent to taking
| the address of the first member of the array.

This quote has been taken out of context and seriously misinterpreted.
It was part of a discussion of ancient (pre-ANSI) C compilers that
simply ignored & when applied to an array. Such compilers interpreted
&a as a, which is in turn interpreted as &a[0] in value contexts. The
above quote was my saying that I know of no justification whatsoever for
that behavior. It has nothing to do with ANSI/ISO C.

-- Larry Jones

I'm getting disillusioned with these New Years. -- Calvin