[RFC] PR6015, snprintf, glibc2.3 and all that...

[Paolo Carlini <pcarlini at unitus dot it>]

Hi all,

I was thinking a bit of some sentences from Benjamin:

"The current code path is not optimal, admittedly. Tricks in the "C" 
library in the glibc-2.3 timeframe will remove this issue from impacting 
modern linux systems. All that is really needed here is some kind of 
hard-wired "C" locale strtold/sscanf function. Or, some elimination of 
this step (long threatened by some contributors.)"
And also his scheme:

  template<typename _Tv>
    int
    __convert_from_v(char* __out, const int __size, const char* __fmt,
		     _Tv __v, const __c_locale& __cloc, int __prec = -1)
    {
      int __ret;
      __c_locale __old = __uselocale(__cloc);
      if (__prec >= 0)
        __ret = snprintf(__out, __size, __fmt, __prec, __v);
      else
        __ret = snprintf(__out, __size, __fmt, __v);
      __uselocale(__old);

      return __ret;
    }


Now, some ideas come to my mind:

1- Which is *really* the 2.3 timeframe? One year? Two years? Can we 
afford to wait that much to have such basic number formatting 
functionality working correctly in a MT environment? (in hindsight, I 
happen to agree quite a bit with submitter ;-)

2- Also, what about non-glibc platforms?

3- Ok, let's suppose we have the support of glibc2.3... Is'nt the scheme 
above "overkilling"?!? As Benjamin said, an "hard-wired" snprintf would 
suffice for this purpose and would solve in one shot both the above 
problems!

4- What's wrong, then, with excerpting /right now/ some of snprintf GPL 
code from glibc2.2, stripping it down to the essential and implementing 
the "hard-wired" approach outlined by Benjamin?

5- In case for some utterly mysterious legal reasons something is not 
ok  with glibc (I cannot imagine what!) there are around nice, free 
standing GPL implementations of snprintf, which would suffice for our 
purposes, for instance: http://www.ijs.si/software/snprintf/

Opinions?

Ciao, Paolo.