[PATCH 0/9] Use more flags parameters instead of global bits in stdio

[Florian Weimer]

On 03/07/2018 08:31 PM, Zack Weinberg wrote:
> I got stuck on the patch to use C99-compliant scanf in _GNU_SOURCE
> mode because the interaction with ldbl-is-dbl was too confusing.  The
> reason it's too confusing is that C99 compliance in scanf, ldbl-is-dbl
> mode in scanf, printf, and strfmon, and fortify mode in printf are
> handled with mode bits on the FILE and thread-global flags that must
> be set and reset at just the right times.  Correct behavior is
> invariably to set and then reset around just one call to a lower-level
> function, and there's a better way to do that: flags parameters.

I looked at how this change interacts with printf format specifier 
callbacks.

There currently does not appear to be a way to determine in the callback 
if an L argument was of double or long double type.  There is code to 
adjust the argument type for double mode:

       case PA_DOUBLE|PA_FLAG_LONG_DOUBLE:
         if (__ldbl_is_dbl)
           {
             args_value[cnt].pa_double = va_arg (*ap_savep, double);
             args_type[cnt] &= ~PA_FLAG_LONG_DOUBLE;
           }
         else
           args_value[cnt].pa_long_double = va_arg (*ap_savep, long double);
         break;

But I don't think args_type is ever read back, and it's not really 
accessible to the second callback function afterwards.

With the thread-local variable, you can run something like this to 
determine if you are in double double or binary64 mode because snprintf 
will not reset the __no_long_double internal TLS variable:

static bool
is_long_double_mode (void)
{
   char buf[64];
   extern __typeof__ (snprintf) snprintf_alias __asm__ ("snprintf");
   snprintf_alias (buf, sizeof (buf), "%.30Lf",
                   1234.0000000000000000000001L);
   puts (buf);
   return strcmp (buf, "1234.000000000000000000000099999997") == 0;
}

There does not seem to be any other way to get at this variable, so I'm 
not sure this is something we need to support going forward.  The flag 
is not copied into the FILE * struct, either.  Considering that 
is_long_double_mode is so inefficient, I don't think this is anything to 
worry about for real code.

For the _IO_FLAGS2_FORTIFY flag, things are a bit different.  It is 
currently copied into the FILE * struct, so it is in theory accessible 
to the printf callbacks.  But it's now in an internal header, and it 
seems unlikely that any code would use it given that it was 
underdocumented before.  Again, this doesn't look a practical problem.

This concern does not apply to _IO_FLAGS2_SCANF_STD because there are no 
scanf hooks, so there isn't any problem there.

So I think this means that the change from thread-local variable and 
in-FILE flags to an argument is conceptually valid.  I have only started 
to review the implementation, though.

Thanks,
Florian