[PATCH v3] ungetc: Guarantee single char pushback

Maciej W. Rozycki macro@redhat.com
Tue Dec 10 13:08:51 GMT 2024


On Mon, 9 Dec 2024, Siddhesh Poyarekar wrote:

> > > >    So what would the problem be if we instead replaced:
> > > >     int _flags2;
> > > > with
> > > >     short int _flags2;
> > > >     char _short_backupbuf[1];
> > > >     char _unused;
> > > 
> > > I don't see an actual problem other than that of an application maybe
> > > using the upper bits of _flags2 for their own logic.  One could make the

 I don't thing an app is allowed to poke at FILE in the first place, it's 
supposed to be an opaque data type.  We have a note at the top to this 
effect (in the first sentence):

/* Caution: The contents of this file are not part of the official
   stdio.h API.  However, much of it is part of the official *binary*
   interface, and therefore cannot be changed.  */

It's not clear to me what "much of it" refers to in the second, except 
(obviously) for the size of the structure.

> > > same argument for unused2, but the defence there is that there's precedent
> > > of struct expansion into unused2; the same can't be said about _flags2.
> > 
> > There is also the question of the probability that we eventually need
> > more than 16 flags here.
> 
> Maciej's argument (in a previous thread) was that the probability of that is
> low enough that we need not care.  Do you disagree?

 Also I don't think the flags need to be contiguous.  It's not clear to me 
even why we're using plain integers and explicit masks in the first place 
rather than bit-fields, which I think would make code just a little bit 
cleaner.

 My only concern would be if we ever needed to consume a FILE data object 
produced by a different version of glibc, in which case we'd have to vary 
the new member ordering by the endianness.  I don't think we need, though; 
the only case I can think of would be pulling a different version of libc 
via dlopen from a static binary and passing a FILE reference to it, but we 
don't support such a scenario AFAIK.

 Have I missed anything here?

  Maciej



More information about the Libc-alpha mailing list