svn commit: r289863 - head/lib/libc/stdio

[John Baldwin]

On Tuesday, October 27, 2015 02:55:43 AM Andrey Chernov wrote:
> On 26.10.2015 20:27, John Baldwin wrote:
> > On Saturday, October 24, 2015 02:23:15 AM Andrey A. Chernov wrote:
> >> Author: ache
> >> Date: Sat Oct 24 02:23:15 2015
> >> New Revision: 289863
> >> URL: https://svnweb.freebsd.org/changeset/base/289863
> >>
> >> Log:
> >>   Since no room left in the _flags, reuse __SALC for O_APPEND.
> >>   It helps to remove _fcntl() call from _ftello() and optimize seek position
> >>   calculation in _swrite().
> > 
> > You could just add a _flags2 to FILE if that would be cleaner.  It should even
> > be MFC'able without being an ABI change since stdio always allocates FILE
> > objects internally and we only export pointers to them.  Programs do not
> > allocate them statically.
> > 
> 
> Thanx, I understand it from your bugzilla answer, but I have a doubt.
> What if some 3rd party port will use static FILE f; and then &f? Some of
> ports may deal with FILE internals and I don't know which ones. I prefer
> rather to not break something there and currently I need only one flag
> and __SALC is not conflicting since used only with _file = -1 and
> __SSTR. If you or somebody else will need another flag and be brave
> enough to add _flags2, this patch can be easily converted.

A static FILE f has never worked.  Even in libc we have a special macro
to initialize internal static FILE objects.  Not too long ago (6.x?) we
used to have a separate xFILE structure in a parallel array of extended
fields.  The only reason was that stdout/err/in resolved to offsets in a
global array.  Peter fixed those to indirect individual pointers, so we
merged xFILE back into FILE.  We've basically broken any software using
static FILE f multiple times.  It is true that some ports may abuse
FILE internals, but they mostly do it via the macros in stdio.h, not
directly.

-- 
John Baldwin