Re: [PATCH 1/2] Fix behaviour of 'is_binary128' in __printf_fp

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 29 Jun 2018, Gabriel F. T. Gomes wrote:

> Should this have an associated bugzilla entry?
> 
> -- 8< --
> Both 'is_long_double' and 'is_binary128' (members of the 'printf_info'
> structure) are used in __printf_fp to select the type of the
> floating-point argument it receives in its 'args' parameter.  When the
> argument is of double type, 'is_long_double' should be set to zero.
> Similarly, when the argument is of long double type, 'is_long_double'
> should be set to one.  More recently (since the addition of the
> _Float128 API), the floating-point argument can also be of _Float128
> type, then 'is_binary128' should be set to one.
> 
> In current __printf_fp, when 'is_binary128' is one, the floating-point
> argument is treated as if it was of _Float128 type, regardless of the
> value of 'is_long_double'.  This is not a problem for strfromd, because
> strfromd always sets 'is_binary128' to zero.  However, it could be a
> problem for users of printf_size, who could be expecting that
> 'is_long_double == 0' meant that the 'args' parameter was of double
> type, regardless of the value of 'is_binary128'.

Well, the main use case of printf_size is being registered as a printf 
handler, not users creating their own printf_info structure.  I'm not 
convinced that calling printf_size with any form of printf_info structure 
that cannot be created by printf functions is valid.

It's certainly true that adding support for float128 versions of printf 
means a documentation patch is required to document is_binary128 in 
stdio.texi.  But why should the semantics be that is_long_double == 0 
overrides is_binary128 rather than is_binary128 being independent of 
is_long_double?  I'd have expected the documentation to say that 
is_binary128 is set alongside is_long_double in the case where printf has 
the 'L' modifier and is called from code with binary128 long double, on a 
platform where that's the third long double format supported by glibc, 
i.e. powerpc64le, but that printf will never set is_binary128 without 
is_long_double (and thus what printf_size does with that combination is 
basically irrelevant, but I'd think it natural for it to make is_binary128 
== 1 take precedence over is_long_double).

(So handlers could potentially, on powerpc64le, themselves deal with both 
ibm128 and binary128 long double, but if not trying to do so - if the 
handler is always built with the same long double format as the printf 
caller - they could just ignore is_binary128.)

-- 
Joseph S. Myers
joseph@codesourcery.com