[Bug middle-end/78703] -fprintf-return-value floating point handling incorrect in locales with a mulltibyte decimal point

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78703

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2016-12-07
           Assignee|unassigned at gcc dot gnu.org      |msebor at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The MB_LEN_MAX value could be specified via a target hook just like the %p
format was.  For unknown targets a conservative MB_LEN_MAX value could be
hardcoded to 6 based on UTF-8.  I'm not aware of an encoding with a value
that's greater than that or an implementation that defines it to a larger
value.  If there was one where MB_LEN_MAX was larger then that value could be
used.

POSIX defines the term Radix Character as "the character that separates the
integer part of a number from the fractional part."  It further defines the
term Character as "a sequence of one or more bytes representing a single
graphic symbol or control code."  I think that makes it fairly clear that the
decimal_point string specified in a locale definition file is meant to be a
single multibyte character.  I haven't tried to see if there is a localedef
utility that would accept a longer string or, if there is one, that the libc
implementation on which it runs would accept it.

That said, although assuming that the length of the decimal point character is
up to MB_LEN_MAX bytes should be safe under these constraints, disabling the
optimization when a floating point directive was detected that produced a
decimal point would another way to avoid the problem.