[PATCH RESEND 01/14] stdio-common: Add tests for formatted scanf input specifiers

[Maciej W. Rozycki]

On Thu, 20 Feb 2025, Joseph Myers wrote:

> > > I don't think it's safe to make any assumptions about whether padding bits 
> > > of x86 (or m68k?) long double are or are not modified by scanf; that may 
> > > depend on the details of what instructions the compiler happens to 
> > > generate in scanf to store the long double value that's been read.  So I 
> > > don't think the strategy of comparing with memcmp is safe in that case, 
> > > unless you first copy just the value bits (and not padding bits) to a 
> > > character array (or other type without room for the padding bits) before 
> > > comparing.
> > 
> >  Speaking of x86 only I fail to see why the compiler should access the 
> > unused 16-bits beyond the underlying hardware data type.  None of the FPU 
> 
> For example, the compiler building the testcase could optimize a sequence
> 
> +  initialize_value (v);
> +  v = read_real (&err);
> 
> to eliminate the initialize_value (= memset) call completely.  It's 
> entirely valid to do so, because the value is immediately overwritten by 
> the assignment, and such an assignment renders the padding bits 
> indeterminate.  And saving on a memset with no semantic effect is also an 
> optimization that makes sense - indeed, one of practical value to real 
> code that clears memory before assigning piecewise, expecting the compiler 
> to remove the clearing except for any non-padding bits not explicitly 
> assigned to.

 Good point, which I missed on this occasion, though it can be dealt with 
an optimisation barrier; I'll place one there, because we don't want the 
compiler in this case to optimise the memset call away.

 However input from Andreas indicates that we need a specialised handler 
anyway, so I'll make this change then too.

 Also from GCC sources I infer the exponent range is wider for the m68k by 
1 on the negative side.  I made real input data such as to include both 
the maximum and the minimum normalised numbers representable in each FP
format.  I'm not sure if it's worth it to account for the additional 
exponent value available with the m68k format and in any case such data 
can be added later on.

  Maciej