Re: Removing stupid, spurious UB in stdio (bikeshed time)

[Rich Felker <dalias@libc.org>]

On Wed, Apr 27, 2016 at 10:56:25AM +0300, Alexander Monakov wrote:
> On Tue, 26 Apr 2016, Rich Felker wrote:
> > There's a lot of nonsense-UB in stdio due to buffer comparisons along
> > the lines of "f->rpos < f->rend". The intent of these comparisons is
> > to simultaneously check that the buffer is initialized for the proper
> > mode (read or write) and that there's data left in it (for reading) or
> > space left (to write) or buffered data to be written out (for write),
> > etc.
> > 
> > Unfortunately, when the buffer is uninitialized for the mode being
> > checked, the comparison becomes NULL<NULL, and while this should
> > obviously be false (since < implies !=), NULL<NULL is actually UB.
> > [snip]
> > So what to do?
> 
> Well, since NULL-NULL and NULL<NULL are well-defined in C++, ... ;)

Ha ha.

> Sorry that I don't offer a more substantial comment; let me just chime in
> on the point that a writeup documenting stdio design, like you say,

OK.

> > I think a good place to start might be coming up with and documenting a
> > clear model for how stdio's buffer internals are supposed to work, what
> > operations are allowed, what invariants hold, etc. based on the above
> > analysis of current UB issues and what the code is doing.
> 
> would be nice to have; you recently noted that setvbuf has restrictions,
> and if there are other non-obvious stuff (especially if musl-specific),
> having it written down should be useful.

Are you talking about the C-standard-imposed restriction that you can
only use setvbuf as the first operation on a new FILE? Or something
else I said that I'm not remembering? I was thinking more about musl's
internally-imposed contracts on internal code (users of the buffer
pointers). Of course external contracts for the stdio API have a role
in determining what the internal interfaces need to be capable of.

Rich