Marking select(2) as restrict

Konstantin Belousov kostikbel at gmail.com
Wed Feb 21 20:10:18 UTC 2018


On Wed, Feb 21, 2018 at 02:15:04PM -0500, Garrett Wollman wrote:
> <<On Wed, 21 Feb 2018 20:59:20 +0200, Konstantin Belousov <kostikbel at gmail.com> said:
> 
> >> [I wrote:]
> >> Compliance with the 2001 POSIX standard (and subsequent versions).
> >> 
> >> After C99, all POSIX interfaces that use pointers were updated to
> >> include the restrict qualifier where applicable.
> 
> > Restrict barely puts any requirements on the implementation, but does on
> > the consumers.  Which is the cause of this discussion.
> 
> I can't speak to this particular case, but my understanding is that
> "restrict" qualifier was only added to arguments if the behavior was
> already unspecified or undefined when the pointers in question were
> aliases (so the consumer was already broken if it did so).  Certainly
> such code has been broken for the better part of two decades.
Undefined != broken, whatever some compiler vendors try to bluff.

> 
> > Also, what incompliance consequences are ?  I am not even sure that the
> > prototype mismatch can be detected by means other than parsing the headers.
> 
> It is permissible for an application to explicitly declare any
> function defined in the standard, so long as it uses the prototype set
> out in the standard.  Also, any vendor wanting POSIX or UNIX
> certification for a derivative system would have to fix it anyway.

For such vendors, backward compatibility with existing software should
have different priorities than for us.  We need a useful software runnable
on the system first, and blue sky stuff like POSIX compliance second.


More information about the freebsd-standards mailing list