Comment by daemin | Hacker News Reader

Comment by daemin | Hacker News Reader

Parent Full thread

The floating point values were valid, they were stored in the text files (unknowingly) in a locale dependent way, either by having a program use a locale sensitive functions to write the values, or because the values were written by hand using the developer's native way of number formatting. The values were then read using the locale dependent functions (like strtod) and if run on a machine with a locale that formatted numbers differently (i.e. using comma for decimal separator) they would return incorrect values.

This caused issues in the game as the values would be significantly different than originally designed, and it would be hard to test for since the people testing the game would usually be using a similar locale to the developer writing the game, and therefore they would only become apparent upon release or wider testing. Now the fix was to explicitly specify the locale before reading the data files, but it still took time to find and implement the fix.

> The floating point values were valid

I would not agree. That sounds to me like the floating point values were not valid, because they were stored in the user's locale and were not intended for the user themselves to consume, but for the developer (who is not the user), or another person (who is also not the user, even if they are a user).

I understand maybe they "should be" valid, but they weren't, and the programmer should not have written files in the users locale that they did not expect the user to edit personally; that they intended to consume mechanically, even if they found it convenient as a human being to edit the file on occasion.

> differently (i.e. using comma for decimal separator) they would return incorrect values.

My suggestion reports an error. strtod() can also detect this error (that's what the second argument is for), so the programmer was not checking if they were using strtod(). This is also not the kind of error the article is talking about detecting.

I don't think you understand the situation so I'll try explaining it one last time.

The developer stored floating point values in a text file written out by whatever means, in the developer's locale (say en-US). These files were shipped with the application and the values were read in using locale sensitive functions on a user's machine (the developer was unaware of the locale sensitive nature of these functions), and the user's locale was something different like de-DE for example. This resulted in a different value being read in compared to the value expected by the developer, therefore causing issues in the rest of the program.

For example the file stored "1.05" which in the developer's en-US locale is "one and five hundredths", but reading it on a different user's locale (de-DE) could result in the value being "105" (one hundred and five), or even "1" (one).

These files are generally not considered to be edited by users (unless they are modding the game, and then they do so without warranty etc).

> I don't think you understand the situation

I definitely do not.

> This resulted in a different value being read in compared to the value expected by the developer

> the developer was unaware of the locale sensitive nature of these functions

> causing issues in the rest of the program

Still sounds like "the programmer caused the bugs in those programs and nobody else" and they would not have that the problem you describe had they either used strtod() correctly or had used my parser.

Are you trying to tell me someone else put the bug in that programmers' code? Or do you actually think you have a pair of locales and a single floating point value that will produce two valid but different floats with my parser?

Reply on news.ycombinator.com