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