[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