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

[Joseph Myers]

On Thu, 20 Feb 2025, Maciej W. Rozycki 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.

So even if the compiler does use an FPU instruction for the assignment in 
both the library and the testcases (rather than code transformations 
resulting in some other form of copy from an intermediate value stored in 
memory, for example), it shouldn't be assumed what value the padding bits 
have before or after that.

Assignments leave padding bits unspecified.  We shouldn't try to guarantee 
or test anything about their values after an assignment (including one 
done by scanf).

There have also been a series of GCC issues involving cases where either 
padding bits were determinate (from memcpy, atomic compare-exchange, etc.) 
but GCC's internal understanding of XFmode values lost information about 
them, or where GCC's internal understanding of XFmode had problems with 
code that made use of bit representations where the value of the explicit 
high significand bit did not correspond to a valid XFmode representation 
(but again, where the representation should have been preserved for that 
particular code).  Such noncanonical representations of course can't arise 
as output from scanf - they're only concerns as inputs - but issues with 
preservation of padding are still of concern.

-- 
Joseph S. Myers
josmyers@redhat.com