Re: Those obnoxious "mktemp is not safe" warnings

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <Pine.LNX.4.32.0103212356010.4551-100000@kern.srcf.societies.cam.ac.uk> you write:
>On Wed, 21 Mar 2001, Zack Weinberg wrote:

>> I'd also point out that we cannot rely on the library to define NULL
>> as ((void *) 0) - it is often 0, and *required* to be plain 0 in
>> C++ (yes, I know about __null)...

>One thing I wondered about: a natural (and I think previously discussed)
>extension of the idea of Marc Espie's __attribute__((__nonnull__)) patch
>would be to check calls to function such as execl that require
>NULL-terminated argument lists.  It was noted on the Austin Group list
>that one of the Austin Group drafts contained defective examples using
>NULL (not cast to (char *) as required).  In principle one might check for
>and warn about the use of uncast NULL in such a case.  But both ways of
>doing this - a magic __null, or making it possible to use integrated CPP
>to ask "is this argument the result of expanding a definition of NULL that
>was defined in a system header" [so unportable to systems that use plain 0
>even if that header used ((void *)0)], seem to involve excess complication
>for the limited gain.  (However, the basic checking for execl-like
>functions that they get a series of char * arguments, made up of the
>correct number of (char * or void *) NULL terminated lists, would make
>sense to implement.)

One more reason for me to get back to that patch whenever I'm not swamped.

Yes, not only does this make sense, but I had expanded my patch to deal
with this, the notion of varargs functions with a sentinel value, the 
sentinel being null most of the time.

With some collaboration from cpp, it should indeed be possible to delay
null expansion to the time it's needed, and to mark whether it comes from
a system header or not... but that's not my turf.