Ben Pfaff <b...@cs.stanford.edu> writes:
> John Darrington <j...@darrington.wattle.id.au> writes:
>
>> If I am right that this is a libc is the independent variable,
>> then we can expect a lot of users to start complaining after
>> their operating systems get upgraded. Mindaugus correctly
>> points out that ignoring the LC_NUMERIC locale is not good
>> anyway (it means that certain aspects of the GUI don't get
>> displayed as users might want). So I think we need to fix the
>> problem, not just the symptom. That is to say, we should set
>> ALL locale categories, and deal with the consequences where, in
>> the past we have relied upon the C locale behaviour.
>>
>> There are several approaches that I can think of:
>>
>> 1. Use write a set of c-printf functions. Unfortunately, there
>> aren't any in gnulib.
>
> John and I talked about this in #pspp today. We agreed to aim
> toward this approach. John started in on it by committing some
> changes to use c_strtod() in place of strtod() where necessary.
It looks like it would be more or less trivial to implement
c_*printf() based on vasnprintf, using a source file like
lib/unistdio/u8-vasnprintf.c but adding:
#define decimal_point_char_defined 1
static char
decimal_point_char (void)
{
return '.';
}
anywhere before the #include "vasnprintf.c", to define a
c_vasnprintf(), then base the other c_*printf() off that in the
same way as e.g. lib/unistdio/u8-snprintf.c.
_______________________________________________
pspp-dev mailing list
pspp-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/pspp-dev
