setlocale and sscanf

[Lenin]

Hello all,

since most of the users of my software are located in Europe, I often have to deal with localization issues. Especially for data export/import features it would be nice to have the ability write/read numeric data to/from localized text files. I checked the stelocale function but found some strange behaviour. The formatting of numbers using printf or sprintf works fine even with localization enabled (in Germany we use comma as decimal separator) but scanning back a number formatted this way fails since the comma is not recognized as decimal separator. Is there a way to change the behaviour of the scanning functions?

I have attached a small example that illustrates the above mentioned behaviour. Of course this only works as described on localized computers, so you probably have to adjust your local settings in Windows beforehand.

The printout of the example on my German Windows is:

Locale Test

Set to "C" locale
Current Locale: "C"
Original Value: 12.345678
Scanned Value : 12.345678

Set to "" locale
Current Locale: ""
Original Value: 12,345678
Scanned Value : 12,000000

As you can see scanning back of the string does not work correctly.

Anybody any suggestions to avoid this and to ensure the software works with different locales?

Thanks

Torsten

[jr_2005]

Do you get the same problem if you use the CVI function Scan(), rather than the ANSI function sscanf()?

JR

[Lenin]

The behaviour is the same with the CVI formatting functions.

Additionally I found out that the following code causes a GPF:

int  ibuf = 0;
setlocale (LC_ALL, "");
sscanf("0", "%x", &ibuf);

The failure only occurs when sscanf is called with a character buffer of "0" and the "%x" format string. 

Looks like a bug to me.

Torsten

[menchar]

I doubt this is the problem, but doesn't the "x" format conversion for scanning require an unsigned argument type?

[Lenin]

According to the MSDN description (http://msdn2.microsoft.com/en-us/library/6ttkkkhh(VS.80).aspx) for the 'x' type character the argument is "pointer to int". But anyway, the problem also occurs with an unsigned argument. I also doubt this is the root problem but it's another issue that is related to switching locales. The same code works perfectly with the default locale.

Torsten

[menchar]

I believe the ISO/IEC 9899:1990 says x format conversion for scanning functions must be unsigned, but I suspect many if not most C compilers will accept int.  I offered that in case a purist implementor had done the locale implementation.

Microsoft has rather famously ignored ANSI / ISO / IEC standards at times.

Yup, locale is implementation dependent, somethings not quite right with it most likely.  I have found errors in CVI's LCC-based  (native CVI) compiler on a couple of occasions.

I've had great fun using the Intel C++ compiler for Windows 10.0 for CVI in release mode - code is typically 50% faster and I've seen 75% faster.  You can download a trial version of it from Intel website - I'm curious what it does in this case.  It kicks out very detailed errors / warnings at compile and link time, maybe it'll catch something.  You do need Visual Studio installed for it to work with CVI.

menchar

[LuisG]

Hello Lenin,

There does seem to be a bug in scanf, when used with a non-English locale. I'll keep you posted, whenever I have some more information. I've entered this as incident 4ASB9MZW.

Thanks for bringing this to our attention!

Luis

[Lenin]

Dear Luis,

thanks for that. I'm still very interested in this issue . Please keep me informed.

[LuisG]

Hello again Lenin,

We've confirmed the bug, and it will be fixed in the next CVI release. There will be a public beta available soon. If you'd like to try out the fix before the release, you can sign up for the beta by visiting ni.com/beta.

Thanks again!

Luis