Re: [PATCH v3 01/11] ldbl-128ibm-compat: Fix selection of GNU and ISO C99 scanf

[Paul E Murphy <murphyp at linux dot ibm dot com>]

On 12/9/19 12:16 PM, Gabriel F. T. Gomes wrote:
> On Mon, 09 Dec 2019, Paul E Murphy wrote:
> > On 12/9/19 10:49 AM, Zack Weinberg wrote:
> > > Credit is actually due to Gabriel; if I understand correctly, I
> > > _introduced_ a bug here!
>
> Zack's patch did the right thing...  However, I started working on
> powerpc's IEEE long double implementation before his patch landed on
> master and I didn't notice the change in default behaviour.  The potential
> bug never really showed up, because ldbl-128ibm-compat is not yet in the
> Implies file, so the __*ieee128 functions were never really exposed.
>
> > I stand corrected.  I wonder how frail some of these tests might become
> > as they age.  Is framework available today to verify tests are linking
> > against the desired variants of a symbol?
>
> The tests in the subsequent patch (2/11) try to make that better, by
> trying to read a long double value with %as when in ISO C99 mode.  Now I'm
> wondering that it should try to read a string (and allocate it
> automatically) in the -D_GNU_SOURCE -std=c89 case, i.e.: also use %as, but
> expect a different output.
>
> Since each case should produce different outputs (even if the input is the
> same), I think that will help verify that the correct symbol gets selected.

There are two tests wrapped in each: One to verify the headers select 
the appropriate variant, secondly verifying the long double 
implementation is correct.  The former is sometimes more complicated 
than ibm128 or ieee128.

I am not suggesting this work be included in this patchset, but would it 
be approaching something like `assert (&(scanf) == &FPTR_EXPECTED 
(scanf))` to this and similar printf tests (e.g fortified printf)?  Such 
could quickly tell us if we need to update our tests.