Re: [Wesnoth-dev] locale-independant number parsing

[Guillaume Melquiond]

On Mon, 7 Feb 2005 21:23:36 +0100, Yann Dirson wrote:
> Looking around a bit, I found that glibc provides a set of functions
> to specify in which language we want the number to be parsed.
> 
> So instead of using atof() we can use strtof_l() if available.

What is that supposed to be? It is neither in my copy of the C99
standard nor in the latest draft of the C standard. A glibc invention?
On my Debian, there isn't even a manpage for it, so I can only guess
what it does based on its signature. I'm not really eager to use a
function "*not* standardized in any form" and described as "a
proof-of-concept implementation" (the emphasis is not mine, these
quotes are directly taken from the header file).

> No objection to check for the availability of this function, and only
> if not, then revert to the setlocale()-based workaround ?

Objections. First, why implement two mechanisms when a single one is
enough? Second, there is a lot more than just atof and strtoxx. You
also need to take into account xxprintf (a lot of them all around the
place), C++ stream inputting (lexical_cast and so on), and C++ stream
outputting (AI values are saved in the savegame files for example). At
least setlocale takes care of them all, without having to review each
one of them to see if it deals with floating-point value and then
correct it if it must be locale independent.

> Was there any specific reason to use atoxx() rather than strtoxx(),
> appart for them to be more concise ?  I note that there are indeed a
> couple of calls to strtoul(), so I guess it is not a portability
> issue.

What's wrong with concision? I don't know why they are here in the
first, but since atof is strictly equivalent to strtod (except for the
behavior on error, as mandated by the standard), why not use it? It's
not like we want to test errno or the end pointer after each
conversion anyway, so better use the shortest form.

> Consistently using strto*_l(), #defined to their standard
> strto*() counterparts when not available, would provide an easy way to
> handle this.

Sorry, you have lost me here. An "easy way" to handle what? You didn't
explain the problem you are trying to solve here, so I can't really
say if your solution is fine or not.

Regards,

Guillaume