Vincent Lefevre([EMAIL PROTECTED])@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.
