[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: lujit - Malformed number
- From: Mike Pall <mikelu-1009@...>
- Date: Sat, 4 Sep 2010 13:15:51 +0200
Alexander Gladysh wrote:
> > Try os.setlocale("C", "numeric") or the equivalent C call after
> > all other libraries have been initialized.
> Um. Mike, are you saying that in LJ2 decimal separator is dependent on locale?
Only if your application or some library in your process
explicitly sets the locale. Which only very few libraries do
nowadays. It's mostly pointless with UTF-8, since very few of the
traditional NLS functions make sense anymore (e.g. isupper()).
> Sorry, but this is horrible! In Lua 5.0 this was a huge PITA (at least
> for me). Changing C locale before loading Lua code and reverting it
> back after all files are loaded? And what if I need to load Lua code
> along the way?
But Lua 5.1 doesn't solve it completely. It does have a workaround
for the parser. But tonumber() still fails if the locale has a
different decimal point. And that workaround introduces a
dependency on localeconv(), which is a no-go with most embedded
Anyway, since the only popular decimal point besides '.' is ',',
I could add a heuristic workaround for that. Except that it would
slow down number parsing if a non-C locale is set (and uglify the
code a lot). Or write my own replacement for strtod(), which is
far from trivial, but would solve other compatibility problems.
Alas, I'm not convinced I really should invest time in either of
these solutions right now.