candide <toto@free.frwr ites:
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.
Good. That is indisputable.
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.
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*.
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.
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.
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.
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.
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.
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.
I try to find out what exactly means "an array and its address are the
same" or "have the same value".
same" or "have the same value".
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.
course.
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, lawrence.jo...@ ugsplm.com wrote:
quotes from clc and comp.std.c regarding this question :
>
-------------------------------- 8<
-------------------------------------------
On 29 juin 2004, 06:06, lawrence.jo...@ ugsplm.com 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.
>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.
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, f...@genesis.de mon.co.uk (Lawrence Kirby) wrote:
>>
>The standard doesn't say so explicitly although a conforming
implementation
*)&s[0]
>(...) The address of an array IS the address of
>it's first element.
>it's first element.
>The standard doesn't say so explicitly although a conforming
>doesn't really have much choice in the matter. (void *)&s and (void
>pretty much have to generate thesameaddress or else standard library
>functions like fread() would have problems.
>functions like fread() would have problems.
same" is made explicit -- they compare equal when converted to void*.
On 7 mai 1999, 09:00, Dennis Ritchie <d...@bell-labs.comwrote:
thing I
useful.
>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
contexts an array name "a" is converted to &a[0], then the closest
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
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
>>
>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.
>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.
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, c2a...@ugrad.cs .ubc.ca (Kazimir Kylheku) wrote:
that
pointer. But the
>Don't be fooled by the fact that the above works. It just so happens
>myarray and &myarray are both expressions that yield the same
>two pointers have a different type.
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 <ks...@mib.orgw rote:
[...]
[...]
>&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.
>the array, which is distict from the address of itsfirstelement .
>They have the "same value" in some sense, but they're of different
>types.
show that it is vague and need qualification. No contradiction that
I can see.
On 11 fév 2008, 19:47, lawrence.jo...@ siemens.com 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)
>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)
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 <larry.jo...@sd rc.comwrote:
>Paul Seale wrote:
>>
>>
>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 *)).
>>
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 *)).
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 ?
"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.
Comment