Re: Little code cleanup
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.
> By "it doesn't make sense", it was not implied that the code was
> wrong, only that it is unneeded
Not much less unneeded than assertion checking and debug messages.
(Well, the only reason why they are useless here is that the
identifier is used before.)
> and resulting of a confusion between an array and a pointer.
There is no confusion. The code could also have been obtained by
a copy-paste where the test was needed before. And there is nothing
wrong with this test.
> 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. And the code is correct and clean.
So, the warning is useless and bad.
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.
[*]
int mutt_strcmp(const char *a, const char *b)
{
return strcmp(NONULL(a), NONULL(b));
}
> 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].
--
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)