alt Hacker NewsThe 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.