<<< Date Index >>>     <<< Thread Index >>>

Re: Little code cleanup



On 2008-03-07 16:01:27 -0500, Derek Martin wrote:
> It should be clear that an array is NOT simply a pointer.

I've never said that they are the same thing. The fact is under some
conditions, arrays are converted into pointers, and Mutt's code is
correct. It does something useless, but the goal of a warning has
never been to detect useless code.

> > There is no confusion. The code could also have been obtained by
> > a copy-paste where the test was needed before. 
> 
> ...which sounds an awful lot to me like the programmer was confused.

Not necessarily. The programmer could think: the test is OK, so no
problem, without wondering about whether the test was useless or not.

> > And there is nothing wrong with this test.
> 
> That's not quite true; the thing which is wrong with it is that it
> needlessly produces a compiler warning which is not interesting or
> necessary for this case.

A code producing a compiler warning is not necessarily wrong. One
may want to get rid of the warning, but it is better to rewrite the
macro (BTW, the missing parentheses are much more a problem than
the warning, even though this doesn't affect the current code).
This would possibly eliminate more useless warnings in the future.

> > There are cases where the test is really necessary (in
> 
> And this is not such a case.

You missed the point: gcc emits the warning even in the cases where
such a test is necessary.

> > array and &array do not evaluate to the same pointer.
> > array is transformed into &array[0].
> 
> That statement is trivially proven to be incorrect with a tiny little
> C program:
> 
> $ cat ptr.c
> #include <stdio.h>
> int main(int argc, char **argv) {
>         char name[] = "foo";
>         printf("value of name = %0x\n", name);
>         printf("value of &name = %0x\n", &name);
>         printf("value of &name[0] = %0x\n", &name[0]);
>         return 0;
> }

LOL! You're testing only *one* implementation. The implementation
of *your* machine. A C implementation is free to crash here because
%x waits for an integer and the arguments are pointers. Of course,
you can use %p to print out the pointer values, but you won't prove
anything with it because the standard requires pointers to void:

       p       The argument shall be a pointer to void. [...]

(so, you would need to cast the pointers to void *, but this is where
the change of the representation occurs if need be, and you will get
3 identical values). If you want to test the memory representation,
you need a bit more complex code (e.g. store the value into memory
and read it back as unsigned char *). But you would still test your
particular implementation.

The C standard has some requirements about pointer representations:

6.2.5 Types

[#26] A pointer to void shall have the same representation and
     alignment requirements as a pointer to a character type.[39]
     Similarly, pointers to qualified or unqualified versions of
     compatible types shall have the same representation and
     alignment requirements. 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.

but a same representation isn't required for &array and &array[0].

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)