Re: [RFC] Another idea for 6015

[Benjamin Kosnik <bkoz at redhat dot com>]

>   template<typename _Tv>
>     int
>     __convert_from_v(char* __out, const int __size, const char* __fmt,
> 		     _Tv __v, const __c_locale&, int __prec = -1)
>     {
>       int __ret;
>       const char* __old = setlocale(LC_ALL, "C");
>        if (__prec >= 0)
> 
> and
> 
>          __ret = snprintf(__out, __size, __fmt, __prec, __v);
>       else
>         __ret = snprintf(__out, __size, __fmt, __v);
>       setlocale(LC_ALL, __old);
>       return __ret;
>     }

First of all, I regard this as low-priority.

There has already been considerable work by this point to make sure that 
the separator in __out is only "." regardless of locale being used. 

I think undoing this is a mistake, or hacking __out so that '.' is 
replaced by the separator expected by snprintf in it's locale is a 
mistake, and no more thread safe than what we've currently got. (Perhaps 
less.) 

One solution that is indeed possible is to just remove the setlocale("C") 
calls and let number formatting fail when LANG =! "C". I didn't like this 
idea, so that's why the code looks like it does now.

I'd prefer your original solution, which was a non-glibc snprintf that can 
be hacked to disregard LANG, so that "C" is assumed in __out. (Since 
that's what we formatted for up to this point.)

BTW, I think Nathan's (quite old, quite vague) proposal is to just do a
loop, extract characters from the char array and smash them into numbers.
I'm not quite sure how limits are going to be tested, etc., which is the
major reason I'm not so hot on this idea. (Considering the issues
surrounding limits consistency on all platforms.) He can correct me if I'm
wrong, or missing clues. 

-benjamin