Re: Little code cleanup
Vincent Lefevre(vincent@xxxxxxxxxx)@2008.03.07 15:28:08 +0100 wrote:
> On 2008-03-06 10:08:34 +0000, Nicolas Bernard wrote:
> > You are missing my point. They EVALUATE to pointers, but they are
> > not pointers.
>
> No, the point is that the test is performed on the pointer itself.
> If you think that the test array == NULL is wrong, then for the same
> reason, writing f(array) where f() waits for a pointer argument is
> also wrong.
No, you are still missing my point. Think of how the compiler see the
code:
when you write "array" as in
if (array)
the compiler just replace "array" by the address of the [beginning of] the
array. Now, when you write "pointer" as in
if (pointer)
the compiler replace "pointer" by code to get the content of pointer
from the memory then check this value, which is an address.
While in both case it evaluates to an address (and, from the point of
view of the programmer, the result is the same), in the first one it is
known at compile time, in the other one it is not (unless some
optimisation makes it known, of course, but that is another story).
> > And the warning of gcc is meaning the same thing.
>
> You're wrong. There are cases where the test is really necessary (in
> the sense that removing it makes the program behave incorrectly),
> because the expression comes from the preprocessor and is sometimes
> an array, sometimes a pointer.
Once again, it is not because you can use pointers and array with the
same syntax that they are the same thing. That the expression can come
from the preprocessor doesn't change anything.
> And the code is correct and clean.
I agree it is correct. I wouldn't say it is clean, but it is a matter of
point of view.
> So, the warning is useless and bad.
Not at all. Or else it is the case with most warnings. For example,
if (a = b)
will generate a warning. Is it false? Most of the time yes as the
programmer really means "if (a == b)", but "if (a = b)" is still a valid
C construct!
Here for example, you can see the warning as meaning: "the programmer
created an array but used it as if it was a pointer so he must be
confused" or simply as "you can optimize the code here by removing a
part of the expression" (which the compiler will probably do anyway).
> The same thing could happen in Mutt. For instance, if mutt_strcmp[*]
> and so on were implemented as macros, one would also have got spurious
> warnings in some cases.
Yes, but I see it as only another proof that macros should be
avoided because such text substitutions bypass type checking and the
programmer is then tempted to use them in incorrect ways. That's why in
C99 it is often cleaner to use static inline functions.
> > If arrays evaluate to pointers it is more because in C you don't
> > have operations on arrays (unlike in Fortran, for example), so it is
> > convenient to transform "array" in "&array" in expressions,
>
> array and &array do not evaluate to the same pointer.
> array is transformed into &array[0].
If array is a real array (i.e., a static one), it is the same thing.
Again, you are confusing arrays and pointers; if you have a dynamic
array (which you access through a pointer), then indeed &ptr and &ptr[0]
are two different things.
Regards,
N.