[Python-Dev] LC_NUMERIC and C libraries

Gustavo J A M Carneiro gjc@inescporto.pt
20 Jul 2003 20:42:51 +0100

A Dom, 2003-07-20 =E0s 10:50, Martin v. L=F6wis escreveu:
> Christian Reis <kiko@async.com.br> writes:
> > > a) it is unlikely that patches are accepted from anybody but
> > >    the author of the code, and
> > > b) it is unlikely that patches are implemented that provide huge
> > >    chunks of the C library.
> >=20
> > I'm afraid I didn't quite understand these two points:
> >=20
> > a) Do you mean to say that the patch should be sent *to* the original
> > author of the locale code? The original author of the code that *call=
> > atof/strtod?
> No. I said that the original author should send us the patches; we
> will only accept them from that author.
> > If the latter I can try and get Alex Larsson to submit the code. Is
> > written permission from the glib team, relicensing the code, not
> > acceptable enough, though?
> We would have to discuss this in the PSF. In general, we want the PSF
> to be owner of all contributed code, see
> http://www.python.org/psf/psf-contributor-agreement.html
> We had bad experience with contributions by non-authors in the past,
> and had to back out changes that we later found we had no right to
> distribute.
> > b) I'm unsure as to how we should proceed without offering alternativ=
> > versions of strtod/formatd (which is what the pystrtod.c file include=
> > AFAICS, the current situation is *caused* by the libc versions not be=
> > LC_NUMERIC-safe. Do you see an alternative?
> It might well be unimplementable. However, if you can find
> platform-specific routines that you can wrap with a small wrapper,
> falling back to strtod if such routines are not available, that might
> be a way out. For example, on glibc, you could use __strtod_l.

  Well, the function does exist, but it's called strtod_l.  I posted a
new patch to sourceforge.  It uses these glibc locale extensions when
available, but falls back to the glib implementations if these
extensions are not available.



Gustavo J. A. M. Carneiro
<gjc@inescporto.pt> <gustavo@users.sourceforge.net>