Re: Legacy _IO_* symbols and Flaot128 transition

[Florian Weimer <fweimer at redhat dot com>]

On 06/29/2018 05:26 PM, Gabriel F. T. Gomes wrote:
> On Fri, 29 Jun 2018, Florian Weimer wrote:
>
> > libio exports a bunch of symbols for historic reasons:
> >
> > _IO_fprintf
> > _IO_printf
> > _IO_sprintf
> > _IO_sscanf
> > _IO_vfprintf
> > _IO_vfscanf
> > _IO_vsprintf
> >
> > These aren't compat symbols yet, but will not be in installed headers
> > for glibc 2.28.  Zack's cleanup patches only turns _IO_vfscanf into a
> > compat symbol (in “Add __vfscanf_internal and __vfwscanf_internal with
> > flags arguments.”).
> >
> > I think we should turn all of them into compat symbols and drop their
> > compatibility wrappers from nldbl_nonshared.a, and avoid adding
> > binary128 compatibility wrappers for them.
>
> Should they be turned into compat symbols *because* they won't be
> installed headers (and we don't want new user code linking against them)?
> Or is there something else to it?

No, it's just a cleanup, and to clarify what's necessary for future work.

I also want to add some minimal test for libnldbl_nonshared.a, and 
reducing its size helps with that.  (I'm aware that on ppc64, the 
current toolchain doesn't support long double as double anymore, but I 
can just lie to the compiler and use double instead, I guess.)

> As for binary128 compatibility wrappers for them, I agree (I haven't
> created these on my branch, so this should already be in sync with your
> suggestions).

Good to know.

Florian