Re: [PATCH 2/9] Add __vfscanf_internal and __vfwscanf_internal with flags arguments.

[Florian Weimer <fweimer at redhat dot com>]

On 03/26/2018 05:27 PM, Gabriel F. T. Gomes wrote:
> On Wed, 07 Mar 2018, Zack Weinberg wrote:
>
> > (It was necessary to introduce ldbl_compat_symbol for _IO_vfscanf.
> > Please check that part of the patch very carefully, I am still not
> > confident I understand all of the details of ldbl-opt.)
>
> It looks good on powerpc64...  Oldest symbol (where long double had the
> same format as double) is still there as a compat symbol with version
> GLIBC_2.3...  The newer symbol, is a bit different, in the sense that it
> is now a compat symbol (it was a default symbol previously).
>
> Here's what readelf has to tell us:
>
> Before the patch set:
>    1355: 00000000001eea70   124 FUNC    GLOBAL DEFAULT   27 _IO_vfscanf@GLIBC_2.3
>    1356: 00000000001f0a98 23552 FUNC    GLOBAL DEFAULT   27 _IO_vfscanf@@GLIBC_2.4
>
> After the patch set:
>    1355: 00000000001f0bd0   136 FUNC    GLOBAL DEFAULT   27 _IO_vfscanf@GLIBC_2.4
>    1356: 00000000001ee968   136 FUNC    GLOBAL DEFAULT   27 _IO_vfscanf@GLIBC_2.3

I think that's correct and intended because there is no user redirect to 
_IO_vfscanf in public headers, and libndbl_nonshared.a does not use this 
interface, either (it uses __nldbl__IO_vfscanf).

> > --- a/sysdeps/ieee754/ldbl-opt/math_ldbl_opt.h
> > +++ b/sysdeps/ieee754/ldbl-opt/math_ldbl_opt.h
> > @@ -20,10 +20,14 @@
> >    long_double_symbol (libc, __GL_##name##_##aliasname, aliasname);
> > # define long_double_symbol_1(lib, local, symbol, version) \
> >    versioned_symbol (lib, local, symbol, version)
> > +# define ldbl_compat_symbol(lib, local, symbol, version) \
> > +  compat_symbol (lib, local, symbol, LONG_DOUBLE_COMPAT_VERSION)
> > #else
> > # define ldbl_hidden_def(local, name) libc_hidden_def (name)
> > # define ldbl_strong_alias(name, aliasname) strong_alias (name, aliasname)
> > # define ldbl_weak_alias(name, aliasname) weak_alias (name, aliasname)
> > +# define ldbl_compat_symbol(lib, local, symbol, version) \
> > +  compat_symbol (lib, local, symbol, version)
>
> I believe that Adhemerval's comment is correct and ldbl_compat_symbol
> should translate to nothing when building static libraries.

The shared library should not contain any definition for the compat 
symbol.  The SHLIB_COMPAT mechanism takes care of that.

But I do wonder if we need this mechanism at all.  Wouldn't it be more 
appropriate to define LONG_DOUBLE_COMPAT_VERSION by default, as 
GLIBC_2_0, and then just use

compat_symbol (libc, __IO_vfscanf, _IO_vfscanf, LONG_DOUBLE_COMPAT_VERSION);

?

This pretends that GLIBC_2_0 already underwent the long double 
transition, and this seems somewhat consistent to me.

Thanks,
Florian