[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.
Bruno
- Re: [PATCH] non-null declarations, (continued)
Re: [PATCH] non-null declarations, Eric Blake, 2009/12/10
Re: [PATCH] non-null declarations, Bruno Haible, 2009/12/10
Re: non-null declarations, recvfrom, sendto, Bruno Haible, 2009/12/10
Re: non-null declarations, recvfrom, sendto, Paolo Bonzini, 2009/12/10
Re: [PATCH] non-null declarations, Dmitry V. Levin, 2009/12/10
Re: [PATCH] non-null declarations, Bruno Haible, 2009/12/10