New LINT gag wanted
Morris Keesan
keesan at bbncca.ARPA
Sat Mar 10 02:52:25 AEST 1984
----------------------------
ok at edai complains:
> #include <stdio.h> /* defines NULL */
> typedef long **ptr;
> ptr foo;
> baz(x)
> ptr x;
> {...}
> ... baz(NULL); ... foo = NULL; ... baz(foo); ...
>
> Lint is perfectly happy with foo = NULL; but complains about the
> "inconsistent usage" of baz's first argument. Given that K&R say
> that 0 is an acceptable pointer of any type, I don't find this at
> all helpful.
Lint is behaving in a perfectly legitimate way here, and is being very
helpful in pointing out a portability problem.
We've been through all of this very recently in this newsgroup. K&R do
NOT say that "0 is an acceptable pointer". What is said about 0 and pointers
in the C Reference Manual (Appendix A of K&R) is:
7.7 Equality operators [p. 190]
. . . A pointer to which 0 has been assigned is guaranteed not to
point to any object, and will APPEAR to be equal to 0; in conventional
usage, such a pointer is considered to be null. [UPPER CASE mine]
[This means that 0 can act like a pointer with the == and != operators]
7.14 Assignment operators [p. 192]
. . . it is guaranteed that assignment of the constant 0 to a pointer
will produce a null pointer distinguishable from a pointer to any object.
[end of citations from Reference Manual]
What you should be doing to shut lint up is casting NULL to the right type
of pointer, e.g.
baz((ptr)NULL);
If you don't want to do this, then you want features added to lint by which you
can declare something like /* COMPATIBLE int ptr */, which would document the
assumption being made, or you could define NULL as ((char *)0), and then issue
an /*ALIGNOK *ptr char*/ as per your following suggestion.
--
Morris M. Keesan
{decvax,linus,wjh12,ima}!bbncca!keesan
keesan @ BBN-UNIX.ARPA
More information about the Comp.lang.c
mailing list