sprintf localized?

  • Thread starter Thread starter Alex
  • Start date Start date
A

Alex

I'm working on an application which generates HTML pages. This application
is distributed to clients worldwide and one of them just reported a problem
that I find very weird.

Consider the following line of code:
sprintf(buffer,_T("var ScaleW=%lf;\r\n"),1.0);

On my machine, the output of this is:
var ScaleW=1.000000;

On his machine, the output is:
var ScaleW=1,000000;

In my mind (MSDN documentation confirms this, somewhat), sprintf should
always put a dot, rather than a comma or whatever is configured in the user
regional settings. I suppose there is a subtlety I haven't grasped yet and
I'm here to ask about it.

I tried changing my regional settings to match his and I am unable to
reproduce the problem. This leads me to think it might be a bug, or related
to some other difference between my system and his. I'm using US settings
myself, while he is using French (France) by default, and French
(Switzerland) for non-Unicode applications (my application is non-Unicode).
As mentionned before, matching those on my side did not reproduce the
problem.

One detail worthy of mentionning is the fact he has the 2.0 dotnet framework
installed on his computer, while I never installed it myself. I'm reluctant
to even installing it on my side since it's my dev machine and I would not
want my future release to require dotnet 2.0 just yet (I suppose installed
vs required are two things, but anyways).

Anybody can enlighten me on this issue?

Thanks alot,

Alex.
 
In my mind (MSDN documentation confirms this, somewhat), sprintf should
always put a dot, rather than a comma or whatever is configured in the user
regional settings. I suppose there is a subtlety I haven't grasped yet and
I'm here to ask about it.

printf (and family) is locale sensitive. This is ANSI C, and this might be
reason why it is not spelled-out in MSDN.

The difference between the MS CRT (C Runtime Library) and other (mostly
UNIX/Linux) CRTs is that the MS one starts with the locales set to match the
system, while the others start with "C" locale.
This is somewhat older observation, I did not try to see if it is still the
case with VS 2005.
 
printf (and family) is locale sensitive. This is ANSI C, and this might be
reason why it is not spelled-out in MSDN.

The difference between the MS CRT (C Runtime Library) and other (mostly
UNIX/Linux) CRTs is that the MS one starts with the locales set to match
the
system, while the others start with "C" locale.
This is somewhat older observation, I did not try to see if it is still
the
case with VS 2005.


Yeah that's what I found out reading around on the internet. The funny thing
is that I cannot reproduce the "problem" on my computer even if I match my
locale to that of the client (same exact settings in Regional settings).
Another thing to note is that our software is already used by thousand of
french clients and none of them reported problems (it's pretty obvious,
since this bug totally ruins the use of our software when numbers are
outputed with commas).

So I don't really know what the exact deal is... Why is it that 1 out of
10000+ clients reports this problem and that even when changing my locale I
cannot reproduce the problem? One thing to note is the client has the 2.0
runtime which we had not tested on prior to this incident. I installed 2.0
on my test machine, set the locale to match the client's, reinstalled the
software and I still can't reproduce the problem.

I'm a bit lost now... It makes no sense.

If anybody has any other pointers, it would really be appreciated.

Thanks,

Alex.
 
One thing to note is the client has the 2.0
runtime which we had not tested on prior to this incident. I installed 2.0
on my test machine, set the locale to match the client's, reinstalled the
software and I still can't reproduce the problem.
I have .NET 2.0 and I still can't reproduce it.
Is it possible that he is running this from a thread that sets the locales
before?

And I was wrong about MS CRT (at least the 2005): the starting locale is "C",
as it should.
 
If anybody has any other pointers, it would really be appreciated.
Just a thought: set the locale to "C" before printf and restore it after.

Will solve the problem, but will not help understanding why this happens to
begin with. I am also curious, but I am afraid without access to that system
there is not much I can tell.
 
Back
Top