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

Discussion in 'C Programming' started by candide, May 23, 2008.

  1. candide

    candide Guest

    Hi,


    I try to find out what exactly means "an array and its address are the
    same" or "have the same value".
    Everybody seems to agree that they doesn't share the same type, of 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, 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.
    >


    -------------------------------------------------------------------------------

    On 31 déc 1996, 10:00, (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.

    -------------------------------------------------------------------------------

    On 7 mai 1999, 09:00, Dennis Ritchie <> wrote:
    > 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.

    -------------------------------------------------------------------------------

    On 25 fév 1996, 10:00, (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.


    -------------------------------------------------------------------------------


    On 19 sep 2006, 21:51, Keith Thompson <> wrote:
    [...]
    > &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.


    -------------------------------------------------------------------------------

    On 11 fév 2008, 19:47, 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)

    -------------------------------------------------------------------------------

    On 7 mai 1999, 09:00, Larry Jones <> wrote:
    > 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 *)).

    --------------------------------- >8
    ---------------------------------------------


    So what ? Is the question undecidable ?
     
    candide, May 23, 2008
    #1
    1. Advertising

  2. Re: Address of an array = address of its 1st element: undecidablequestion ?

    Richard Heathfield <> wrote:
    > candide said:
    > > I try to find out what exactly means "an array and
    > > its address are the same"

    >
    > They aren't. An array is an array. An address is a
    > pointer value. These are not the same thing. If you
    > mean that &array and &array[0] are the same,
    > they aren't. They have different types.
    >
    > > or "have the same value".

    >
    > If you try to take the value of an array, what you
    > actually get is the value of a pointer to the first
    > member of the array. That doesn't mean that an array
    > is the same as a pointer. If you mean that &array
    > and &array[0] have the same value, they don't. They
    > have different types.


    What about (void *) &array == (void *) &array[0]?

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

    >
    > And therefore they cannot have the same value.


    So 1 is _not_ the same value as 1u?

    Can you then tell me what the standard means when
    it says...

    "The range of nonnegative values of a signed
    integer type is a subrange of the corresponding
    unsigned integer type, and the representation
    of the same value in each type is the same."
    ^^^^^^^^^^

    Either 'same value' is independant of type, or
    above line makes no sense. Which is it?

    --
    Peter
     
    Peter Nilsson, May 23, 2008
    #2
    1. Advertising

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

    candide <> writes:

    > 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, 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, (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 <> wrote:
    >> 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, (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 <> wrote:
    > [...]
    >> &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, 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 <> wrote:
    >> 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.
     
    Ben Bacarisse, May 23, 2008
    #3
  4. candide

    Guest

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

    On May 22, 9:00 pm, Ben Bacarisse <> wrote:
    > candide <> writes:
    > > 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
     
    , May 23, 2008
    #4
  5. Re: Address of an array = address of its 1st element: undecidablequestion ?

    On Fri, May 23, 2008 at 02:18:47AM +0200, candide wrote:
    > Hi,
    >
    >
    > I try to find out what exactly means "an array and its address are the
    > same" or "have the same value".
    > Everybody seems to agree that they doesn't share the same type, of course.


    I am glad that this discussion comes up again, as it is not merely of
    academic nature. I don't really think that one truely wants to
    compare (void*)&array to (void*)array, but consider the following:

    I have a chunk of data:

    float A[256];

    And you would like to consider this as 32x8 matrix.
    You can of course do A[32*i+j] for the (i,j)-th element, but it is
    much more convenient to put it into an array form:

    float (*B)[8]=(void*)A;

    The (void*) here is merely to shut up the compiler (ie. to fulfil the language
    constraints). B is a pointer to the first one of a series (float[8]) arrays.

    Then, after using this layout of the data, I realise that I need an other
    matrix format: 16x16, so I write.

    float (*C)[16]=(void*)A;


    Let now the experts tell if accessing the array members through B and C
    invoke an undefined behaviour. In my understanding it does not, but it might
    be far from the truth.

    Szabolcs
     
    Szabolcs Borsanyi, May 23, 2008
    #5
  6. candide

    Bartc Guest

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

    "pete" <> wrote in message
    news:...
    > Peter Nilsson wrote:
    >
    >> So 1 is _not_ the same value as 1u?

    >
    > Only one of those, is greater than -1.
    >
    > (1u < -1)


    This is ridiculous and dangerous behaviour on the part of C;

    (a<b) /* True */

    ++a; ++b;

    (a<b) /* Now false! And without any wrap or overflow */

    Obviously some amateurish work in the early days of C which later had to be
    condoned by the standard.

    The correct handling would have been to have cast both into a type
    encompassing both values before comparing, or to give a warning.

    (OK, my own compiler efforts do exactly the same, but my compiler isn't used
    for supercomputers or mission critical software)


    --
    Bartc
     
    Bartc, May 23, 2008
    #6
  7. Re: Address of an array = address of its 1st element: undecidable question ?

    writes:

    > On May 22, 9:00 pm, Ben Bacarisse <> wrote:
    >> candide <> writes:
    >> > 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.
     
    Ben Bacarisse, May 23, 2008
    #7
  8. candide

    Guest

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

    On May 23, 12:59 pm, "Bartc" <> wrote:
    > "pete" <> wrote in message
    >
    > news:...
    >
    > > Peter Nilsson wrote:

    >
    > >> So 1 is _not_ the same value as 1u?

    >
    > > Only one of those, is greater than -1.

    >
    > > (1u < -1)

    >
    > This is ridiculous and dangerous behaviour on the part of C;

    No, it is not. It would be ridiculous and dangerous if anything else
    happened.
    What you're essentially saying here is that 1u > UINT_MAX should be
    true, or rather, that it's ridiculous it's true.
    Add to that, that (unsigned)1 is also different than 1 or 1u.
    It doesn't make sense until you learn about integer promotions in
    expressions.
     
    , May 23, 2008
    #8
  9. candide

    Bartc Guest

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

    "Eric Sosman" <> wrote in message
    news:1211555836.742807@news1nwk...
    > wrote:
    >> On May 23, 12:59 pm, "Bartc" <> wrote:
    >>> "pete" <> wrote in message
    >>>
    >>> news:...
    >>>
    >>>> Peter Nilsson wrote:
    >>>>> So 1 is _not_ the same value as 1u?
    >>>> Only one of those, is greater than -1.
    >>>> (1u < -1)
    >>> This is ridiculous and dangerous behaviour on the part of C;

    >> No, it is not. It would be ridiculous and dangerous if anything else
    >> happened.
    >> What you're essentially saying here is that 1u > UINT_MAX should be
    >> true, or rather, that it's ridiculous it's true.
    >> Add to that, that (unsigned)1 is also different than 1 or 1u.
    >> It doesn't make sense until you learn about integer promotions in
    >> expressions.

    >
    > Having embarrassed myself once already on this topic,
    > it is with some trepidation that I suggest that's not what
    > he was saying. Here's the situation I think he had in mind:


    I was merely talking about the (1u<-1) above:

    #include <stdio.h>

    int main(void)
    {
    unsigned int a=1;
    signed int b=-1;

    if (a<b) printf("A<B\n"); else printf("A>=B\n");

    ++a;
    ++b;

    if (a<b) printf("A<B\n"); else printf("A>=B\n");

    }

    The increment changes 1 to 2, and -1 to 0, nothing dramatic.

    The problem seems to me that comparing unsigned to signed (by I think
    treating both as unsigned) seems a little dangerous.

    --
    bartc
     
    Bartc, May 23, 2008
    #9
  10. Re: Address of an array = address of its 1st element: undecidable question ?

    Eric Sosman <> writes:
    > Eric Sosman wrote:
    >> Bartc wrote:
    >>> "pete" <> wrote in message
    >>> news:...
    >>>> Peter Nilsson wrote:
    >>>>
    >>>>> So 1 is _not_ the same value as 1u?
    >>>> Only one of those, is greater than -1.
    >>>>
    >>>> (1u < -1)
    >>>
    >>> This is ridiculous and dangerous behaviour on the part of C;
    >>>
    >>> (a<b) /* True */
    >>>
    >>> ++a; ++b;
    >>>
    >>> (a<b) /* Now false! And without any wrap or overflow */

    >> Perhaps I'm overlooking something obvious, [...]

    >
    > Aha! Never mind; I overlooked something obvious. Still,
    > your characterization of pointer arithmetic as "amateurish
    > work in the early days of C" is silly.


    Bartc was talking about comparisons between unsigned and signed
    integers, not pointer arithmetic.

    (Eric, I can't think of an example of the above problem involving
    pointer arithmetic. Do you have one in mind?)

    Here's an example of what Bartc was talking about:

    #include <stdio.h>
    int main(void)
    {
    unsigned a = 1;
    int b = -1;
    printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
    ++a; ++b;
    printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
    return 0;
    }

    The output is:

    1U < -1
    2U > 0

    And the reason is that when the "<" operator has signed and unsigned
    operands of the same rank, the signed operand is converted to the
    unsigned type before the operator is applied (see "Usual arithmetic
    conversions", C99 6.3.1.8), so the value -1 is converted to UINT_MAX.

    Note that gcc, for example, warns about the
    comparisons in my sample program:
    c.c:6: warning: comparison between signed and unsigned
    c.c:8: warning: comparison between signed and unsigned

    The alternative would have been to convert the unsigned operand to the
    signed type -- but such a conversion can yield an
    implementation-defined result (or raise an implementation-defined
    signal). Conversion from signed to unsigned is well defined.

    Upthread, Bartc wrote:
    | The correct handling would have been to have cast both into a type
    | encompassing both values before comparing, or to give a warning.

    (You mean convert, not cast.)

    There won't necessarily be such a type. Note that the type would have
    to encompass the full ranges of the types of both operands, not just
    the values of the operands (which aren't known to the compiler).

    As I recall, there was considerable controversy in the pre-ANSI era
    between "value-preserving" and "signedness-preserving" conversions.
    Some compilers, did it one way, some did it the other way. Both
    approaches have problems, and the committee had to choose one or the
    other. Probably the fact that unsigned-to-signed conversion is
    implementation-defined was a large part of what motivated their
    decision.

    Another possibility might have been to disallow such comparisons, so
    that if you want to compare a signed value to an unsigned value you
    have to convert one of them explicitly. That might actually have been
    less confusing.

    Or they could have required the operators to be further "overloaded"
    at the language level so that these:
    u < i
    i < u
    i < i
    u < u
    actually invoke four different operations rather than just two. The
    same would have had to be done for most other operators, and the
    result would have been a substantial burden on compiler writers (how
    would you actually implement a long long vs. unsigned long long
    comparison?) for some fairly unusual cases.

    The best workaround is to avoid such comparisons in your own code. If
    you find yourself comparing a signed quantity to an unsigned quantity,
    it's likely (but by no means certain) that they both simply should
    have been of the same type in the first place.

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, May 23, 2008
    #10
  11. Re: Address of an array = address of its 1st element: undecidable question ?

    Ben Bacarisse <> writes:
    > writes:
    >
    >> On May 22, 9:00 pm, Ben Bacarisse <> wrote:
    >>> candide <> writes:
    >>> > 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) <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"
     
    Keith Thompson, May 23, 2008
    #11
  12. candide

    Bartc Guest

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

    "Keith Thompson" <> wrote in message
    news:...
    > Eric Sosman <> writes:
    >> Eric Sosman wrote:
    >>> Bartc wrote:
    >>>> "pete" <> wrote in message
    >>>> news:...
    >>>>> Peter Nilsson wrote:
    >>>>>
    >>>>>> So 1 is _not_ the same value as 1u?
    >>>>> Only one of those, is greater than -1.
    >>>>>
    >>>>> (1u < -1)
    >>>>
    >>>> This is ridiculous and dangerous behaviour on the part of C;
    >>>>
    >>>> (a<b) /* True */
    >>>>
    >>>> ++a; ++b;
    >>>>
    >>>> (a<b) /* Now false! And without any wrap or overflow */
    >>> Perhaps I'm overlooking something obvious, [...]


    > Here's an example of what Bartc was talking about:
    >
    > #include <stdio.h>
    > int main(void)
    > {
    > unsigned a = 1;
    > int b = -1;
    > printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
    > ++a; ++b;
    > printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
    > return 0;
    > }
    >
    > The output is:
    >
    > 1U < -1
    > 2U > 0
    >
    > And the reason is that when the "<" operator has signed and unsigned
    > operands of the same rank, the signed operand is converted to the
    > unsigned type before the operator is applied (see "Usual arithmetic
    > conversions", C99 6.3.1.8), so the value -1 is converted to UINT_MAX.
    >
    > Note that gcc, for example, warns about the
    > comparisons in my sample program:
    > c.c:6: warning: comparison between signed and unsigned
    > c.c:8: warning: comparison between signed and unsigned


    I did try (obviously not too hard) to get a warning from gcc; it needs
    something more than -Wall I think.

    >
    > The alternative would have been to convert the unsigned operand to the
    > signed type -- but such a conversion can yield an
    > implementation-defined result (or raise an implementation-defined
    > signal). Conversion from signed to unsigned is well defined.
    >
    > Upthread, Bartc wrote:
    > | The correct handling would have been to have cast both into a type
    > | encompassing both values before comparing, or to give a warning.
    >
    > (You mean convert, not cast.)


    What's the difference? I thought conversions between any numeric types were
    all casts.

    --
    Bartc
     
    Bartc, May 23, 2008
    #12
  13. candide

    Bartc Guest

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

    "Eric Sosman" <> wrote in message
    news:1211562368.634431@news1nwk...
    > Bartc wrote:
    >> [...]
    >> I was merely talking about the (1u<-1) above:
    >>
    >> #include <stdio.h>
    >>
    >> int main(void)
    >> {
    >> unsigned int a=1;
    >> signed int b=-1;
    >>
    >> if (a<b) printf("A<B\n"); else printf("A>=B\n");
    >>
    >> ++a;
    >> ++b;
    >>
    >> if (a<b) printf("A<B\n"); else printf("A>=B\n");
    >>
    >> }
    >>
    >> The increment changes 1 to 2, and -1 to 0, nothing dramatic.

    >
    > But you said (in snippage that occurred a few messages
    > ago) that the example was "without any wrap or overflow."
    > Surely there's a "wrap" in the conversion of -1 to UINT_MAX?


    That was here:

    "(a<b) /* True */
    ++a; ++b;
    (a<b) /* Now false! And without any wrap or overflow */"

    I meant with no wrap/overflow occuring in the increment operations, because
    they are still working well within their limits at that point.

    >Yes, it can be dangerous, and some compilers warn about it.
    > But what would you have instead? Make the attempted comparison
    > a compile-time error?


    I said that having A<B but (A+1)>=(B+1), without "+" exceeding any numeric
    limits, was ridiculous. I think it still is. But not much can be done about
    it now, except to be aware of it or to avoid the problem by not mixing
    signed/unsigned.

    --
    bartc
     
    Bartc, May 23, 2008
    #13
  14. Re: Address of an array = address of its 1st element: undecidable question ?

    Eric Sosman <> writes:
    > Bartc wrote:
    >> [...]
    >> I was merely talking about the (1u<-1) above:
    >> #include <stdio.h>
    >> int main(void)
    >> {
    >> unsigned int a=1;
    >> signed int b=-1;
    >> if (a<b) printf("A<B\n"); else printf("A>=B\n");
    >> ++a;
    >> ++b;
    >> if (a<b) printf("A<B\n"); else printf("A>=B\n");
    >> }
    >> The increment changes 1 to 2, and -1 to 0, nothing dramatic.

    >
    > But you said (in snippage that occurred a few messages
    > ago) that the example was "without any wrap or overflow."
    > Surely there's a "wrap" in the conversion of -1 to UINT_MAX?
    >
    >> The problem seems to me that comparing unsigned to signed (by I
    >> think treating both as unsigned) seems a little dangerous.

    >
    > Yes, it can be dangerous, and some compilers warn about it.
    > But what would you have instead? Make the attempted comparison
    > a compile-time error? The tactic of "widen *both* operands"
    > isn't always available, as for example when comparing intmax_t
    > to uintmax_t (by definition, the widest integers in the West).


    I can't speak for Bartc, but yes, in my opinion making such a
    comparison a constraint violation would have avoided confusion. In
    the rare cases where you want to compare an unsigned value to a signed
    value, it's not clear how the comparison should be done, except on a
    case-by-case basis. Given a requirement to define it *somehow*, I
    have no problem with the decision made by the standard committee, but
    forcing programmers to make the conversion explicit could have avoided
    a great deal of confusion. (It probably would also have broken a
    great deal of pre-ANSI code, but at least it wouldn't have done so
    quietly.)

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, May 23, 2008
    #14
  15. Re: Address of an array = address of its 1st element: undecidable question ?

    Keith Thompson <> writes:

    > Ben Bacarisse <> writes:
    >> writes:
    >>
    >>> On May 22, 9:00 pm, Ben Bacarisse <> wrote:
    >>>> candide <> writes:
    >>>> > 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.
     
    Ben Bacarisse, May 23, 2008
    #15
  16. Re: Address of an array = address of its 1st element: undecidable question ?

    Eric Sosman <> writes:
    > Keith Thompson wrote:

    [...]
    >> Bartc was talking about comparisons between unsigned and signed
    >> integers, not pointer arithmetic.
    >> (Eric, I can't think of an example of the above problem involving
    >> pointer arithmetic. Do you have one in mind?)
    >> Here's an example of what Bartc was talking about:
    >> #include <stdio.h>
    >> int main(void)
    >> {
    >> unsigned a = 1;
    >> int b = -1;
    >> printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
    >> ++a; ++b;
    >> printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
    >> return 0;
    >> }

    >
    > I'd have thought that "without any wrap" would have
    > ruled this one out, since the conversion of -1 to unsigned
    > involves what I'd call a "wrap."
    >
    > For the pointer example, see my reply to vippstar in
    > this thread. (And I see Bartc's replied to that reply
    > confirming your understanding. I still don't understand
    > why he doesn't think there's a "wrap" in (unsigned)-1,
    > though.)


    I think his point is that there's no wrap in incrementing a and b, and
    yet these non-wrapping increments changed the "<" relationship between
    them. It is a bit counterintuitive, even though there are good
    underlying reasons for the behavior.

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, May 23, 2008
    #16
  17. Re: Address of an array = address of its 1st element: undecidablequestion ?

    Ben Bacarisse wrote:
    > writes:
    >
    >> On May 22, 9:00 pm, Ben Bacarisse <> wrote:
    >>> candide <> writes:
    >>>> 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
     
    Yevgen Muntyan, May 23, 2008
    #17
  18. Re: Address of an array = address of its 1st element: undecidable question ?

    "Bartc" <> writes:
    > "Keith Thompson" <> wrote in message
    > news:...

    [...]
    >> (You mean convert, not cast.)

    >
    > What's the difference? I thought conversions between any numeric types were
    > all casts.


    Nope.

    A conversion is an operation that translates a value of one type to
    another type.

    A cast is an operator that explicitly specifies a conversion.

    Some conversions are specified by cast operators; some are implicit.
    There's no such thing as an "implicit cast".

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, May 23, 2008
    #18
  19. Re: Address of an array = address of its 1st element: undecidable question ?

    Ben Bacarisse <> writes:
    > Keith Thompson <> writes:
    >
    >> Ben Bacarisse <> writes:
    >>> writes:
    >>>
    >>>> On May 22, 9:00 pm, Ben Bacarisse <> wrote:
    >>>>> candide <> writes:
    >>>>> > 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) <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"
     
    Keith Thompson, May 23, 2008
    #19
  20. Re: Address of an array = address of its 1st element: undecidablequestion ?

    Richard Heathfield wrote:
    > Peter Nilsson said:
    >
    >> Richard Heathfield <> wrote:
    >>> candide said:
    >>>> I try to find out what exactly means "an array and
    >>>> its address are the same"
    >>> They aren't. An array is an array. An address is a
    >>> pointer value. These are not the same thing. If you
    >>> mean that &array and &array[0] are the same,
    >>> they aren't. They have different types.
    >>>
    >>>> or "have the same value".
    >>> If you try to take the value of an array, what you
    >>> actually get is the value of a pointer to the first
    >>> member of the array. That doesn't mean that an array
    >>> is the same as a pointer. If you mean that &array
    >>> and &array[0] have the same value, they don't. They
    >>> have different types.

    >> What about (void *) &array == (void *) &array[0]?

    >
    > The expressions (void *) &array and (void *) &array[0] have the same type -
    > i.e. void *. Therefore, they /can/ have the same value (and may well
    > have).
    >
    >>>> Everybody seems to agree that they doesn't share
    >>>> the same type, of course.
    >>> And therefore they cannot have the same value.

    >> So 1 is _not_ the same value as 1u?

    >
    > Correct - it isn't. 1 has type int, whereas 1u has type unsigned int. They
    > may well (and in fact do) share a great many characteristics, but they are
    > *not* the same. I'd have explained why, if pete had not already done so.
    >
    >> Can you then tell me what the standard means when
    >> it says...
    >>
    >> "The range of nonnegative values of a signed
    >> integer type is a subrange of the corresponding
    >> unsigned integer type, and the representation
    >> of the same value in each type is the same."
    >> ^^^^^^^^^^

    >
    > It means that the Standard isn't as picky about its use of the word "value"
    > as it should be. :)


    It is picky all right. 1 and 1u have the same value,
    the real number 1. 6.3.1 quite agrees with it, and
    there is no reason to think otherwise. Quoted text
    says so, by the way.

    >> Either 'same value' is independant of type, or
    >> above line makes no sense. Which is it?

    >
    > In my opinion (since you ask!), the quoted line makes no sense. I'd have
    > been happier if it had said something like "the same numerical value" or
    > some such weasel phrase.


    It doesn't have to because the value here *is*
    the numerical value. For floating point numbers
    you add special arithmetical entities from whatever
    arithmetic model you use - NAN and INF for IEE????
    for instance. Complex types add complex numbers.
    Etc.

    > Two values can have the same numerical value
    > despite being intrinsically different.


    They are not. For example, arithmetic operations
    are not defined on representations, they are defined
    on values. 1 + 1 is two and 1u + 1u is two; -1 * 1u
    is some shit not because values are wrong or bad,
    but because you do not multiply values in this case:
    first you do the conversion, *then* you get two unsigned
    values, then you multiply them, then you get some
    shit.

    > Consider, for example, the
    > differences and similarities between -40degF (or, if you prefer, the very
    > different value -40degC) and -$40. If C had a Fahrenheit (or Celsius) type
    > and a dollar type, an assignment of one to the other (presumably with a
    > cast!) might well result in the numerical value -40 being preserved, and
    > they might even be represented in the same way internally. That doesn't
    > mean that degrees are dollars or that dollars are degrees.


    Nice example, except it's irrelevant. C doesn't have
    any types measuring something, all numerical types are
    just numbers. It could, and in that case, it would...

    Yevgen
     
    Yevgen Muntyan, May 23, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. arnuld
    Replies:
    21
    Views:
    1,068
    Old Wolf
    Apr 4, 2007
  2. Summercool
    Replies:
    2
    Views:
    431
    Summercool
    Mar 1, 2008
  3. thunk
    Replies:
    1
    Views:
    315
    thunk
    Mar 30, 2010
  4. thunk
    Replies:
    0
    Views:
    486
    thunk
    Apr 1, 2010
  5. thunk
    Replies:
    14
    Views:
    625
    thunk
    Apr 3, 2010
Loading...

Share This Page