Re: [PATCH] non-null declarations

[Eric Blake]

Bruno Haible <bruno <at> clisp.org> writes:

> > >  extern int scandir (const char *dir, struct dirent ***namelist,
> > >               int (*filter) (const struct dirent *),
> > > -             int (*cmp) (const struct dirent **, const struct dirent 
**));
> > > +             int (*cmp) (const struct dirent **, const struct dirent **))
> > > +     _GL_ARG_NONNULL ((1, 2, 4));
> > 
> > Is there any desire to provide guaranteed extension semantics that cmp can 
be 
> > NULL in order to get an unsorted subset returned?
> 
> I don't think this would be portable. You can in any case get an unsorted
> result by passing a cmp function that always returns 0:
>   int cmp (const struct dirent **d1, const struct dirent **d2) { return 0; }

Not necessarily true.  POSIX states, for qsort, that even if a function 
provides total ordering (which always returning 0 does), "If two members compare
as equal, their order in the sorted array is unspecified."  And since 
alphasort/scandir mentions qsort, it implies that the sorting done by scandir 
will be as if by qsort.

> > > +extern int setenv (const char *name, const char *value, int replace)
> > > +     _GL_ARG_NONNULL ((1));
> > 
> > POSIX and gnulib guarantee that calling this with NAME set to NULL will 
> > gracefully fail with EINVAL, so maybe we shouldn't list this one.
> 
> But it's a dubious use of the setenv function, and therefore it will be
> beneficial to warn for this case.

Agreed.  And given the Austin Group feedback, I'll go ahead and relax our 
setenv implementation to no longer reject BSD solely on the basis of failure to 
handle null, and our testsuite to no longer call setenv(NULL,,).

> > Bug: Arg 5 can be NULL, since POSIX states that "The send( ) function is 
> > equivalent to sendto( ) with a null pointer dest_len argument" (well, 
that's 
> > also a bug in POSIX, since dest_len is socklen_t; it obviously meant a null 
> > dest_addr argument).
> 
> The only indication in the sendto specification that I can see is the
> sentence "If the socket is connection-mode, dest_addr shall be ignored."
> So, if a user knows that the socket is connection-mode, he may pass NULL.
> But I would qualify this as dangerous practice, therefore I leave the warning
> in.

My point was that send(a,b,c,d) is the same as sendto(a,b,c,d,NULL,0).  I guess 
your point is that if the user is intentionally passing NULL to arg 5 of 
sendto, they should probably use send() instead.

-- 
Eric Blake