[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] non-null declarations

From: Bruno Haible
Subject: Re: [PATCH] non-null declarations
Date: Thu, 10 Dec 2009 19:33:22 +0100
User-agent: KMail/1.9.9

Eric Blake wrote:
> [about scandir]
> > > 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.

OK. But who will benefit if a platform extends scandir() in such a way?
  - The feature of supporting cmp = NULL will be unportable.
  - The time saved by not sorting the result is negligible compared to the
    disk accesses.

> [about setenv and unsetenv]
> 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,,).

Yes, that makes sense to me.

> [about sendto]
> > > 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.

My point is that the spec of 'sendto' should be complete in the page that
describes 'sendto'. When I take the spec of 'sendto' literally, arg 5 cannot
be NULL, and the sentence about the send() function is a bug in the non-
normative part of POSIX.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]