sscanf and int64 in Win32 and Unix - different results?

[zardoz]

I've got this problem:


unsigned long long lTemp;
char cLargeNum[]="1324567890";
sscanf(clargeNum,"%llu",&lTemp);

which under Win32 isn't working*. My program needs to compile under
posix so no Win32 specials allowed....

* lTemp = -368934881...
* if I mess around with signing I can get huge but incorrect poitive
numbers.
* I'm pretty sure it works in unix (but without a debugger I can only
sprintf with %lld as an argument .. this could hide the conversion
error I spose?)

 

[Richard Bos]

I've got this problem:

unsigned long long lTemp;
char cLargeNum[]="1324567890";
sscanf(clargeNum,"%llu",&lTemp);

which under Win32 isn't working*. My program needs to compile under
posix so no Win32 specials allowed....

* lTemp = -368934881...

This is impossible. lTemp is unsigned, so it cannot be negative. Where
did you get this value?

* if I mess around with signing I can get huge but incorrect poitive
numbers.
* I'm pretty sure it works in unix (but without a debugger I can only
sprintf with %lld as an argument .. this could hide the conversion
error I spose?)

If your sscanf() understands %llu, so should your printf(). But yes,
using the wrong specifier for your object could hide other errors.

I suspect that the above is not your actual code (if only because it
contains a typo), and that the error is elsewhere in your code. Dev-C++
has no problem with this:

#include <stdio.h>

int main(void)
{
unsigned long long temp;
char largenum[]="1324567890";
sscanf(largenum, "%llu", &temp);
printf("%llu", temp);
getchar();
}

The output is as expected. What is your exact code? Reduce to the
smallest part that still shows the error, then copy, don't retype, into
your news client, please - this avoids typos.

Richard

 

[websnarf]

I've got this problem:

unsigned long long lTemp;
char cLargeNum[]="1324567890";
sscanf(clargeNum,"%llu",&lTemp);

which under Win32 isn't working*. My program needs to compile under
posix so no Win32 specials allowed....

* lTemp = -368934881...
* if I mess around with signing I can get huge but incorrect poitive
numbers.
* I'm pretty sure it works in unix (but without a debugger I can only
sprintf with %lld as an argument .. this could hide the conversion
error I spose?)

1. Older Windows compilers do not support "%llu" but instead use
"%I64u". I have written up a file named "stdint.h" that you can find
here:

http://www.pobox.com/~qed/stdint.h

which solves the problem for most platforms. Instead of the platform
dependent "%llu" or "%I64u" you would write:

"%" PRINTF_INT64_MODIFIER "u"

After including the stdint.h file.

2. If you neglect to #include <stdio.h> at the beginning its possible
that the parameters are not passed to the underlying library correctly.
(Though this is very unlikely to be the problem in this case.)

 

[Richard Bos]

1. Older Windows compilers do not support "%llu" but instead use
"%I64u". I have written up a file named "stdint.h" that you can find
here:

[ Snip! ]

which solves the problem for most platforms. Instead of the platform
dependent "%llu" or "%I64u" you would write:

"%" PRINTF_INT64_MODIFIER "u"

You do realise that this makes your header incompatible with the ISO C99
Standard?

Richard

 

[zardoz]

Agreed about the signing thing. I cut and pasted your program into a
new dev studio console app and though it printed out the right number
the debugger says the long long is
14757395256856235346.

my compiler is vc dotnet 1.1 (and gcc 3 something under cygwin)

presumably you see the same thing?

thanks.

 

[zardoz]

eg doing a log on the number indicates that what's in memory isn't the
same as the input / output

#include <stdio.h>
#include <math.h>

int main(void)
{
unsigned long long temp;
char largenum[]="1324567890";
sscanf(largenum, "%llu", &temp);

int Rtn=log10((long double)temp);
printf("%llu : ", temp);
printf("%i", Rtn);

getchar();
}

Win32
1324567890 : 19

posix
1324567890 : 9

 

[websnarf]

1. Older Windows compilers do not support "%llu" but instead use
"%I64u". I have written up a file named "stdint.h" that you can find
here:

[ Snip! ]

which solves the problem for most platforms. Instead of the platform
dependent "%llu" or "%I64u" you would write:

"%" PRINTF_INT64_MODIFIER "u"

You do realise that this makes your header incompatible with the ISO C99
Standard?

Which matters what to who?

 

[Mark McIntyre]

Which matters what to who?

I suppose it would matter to anyone who
a) cares about being standards-compliant and /or
b) wants to write code that won't break in a few years time and/or
c) expects at any time to get employed in the same company as me

Since you seem not to fall into any of those categories (certainly not
the last one, I have to tell you), its not a problem for you to use
it.

 

[websnarf]

I suppose it would matter to anyone who
a) cares about being standards-compliant and /or

The file is fully C89 compliant as far as I can determine.

b) wants to write code that won't break in a few years time and/or

Well no problems there! Since C89 is the final standard for C.

Actually there is an issue with C++; they may cannibalize parts of the
C99 proposal and put it into their standard. However, I can just claim
that this is meant just for C, where there is, of course, no issue.

c) expects at any time to get employed in the same company as me

Indeed, this one I have problems with. I don't think I could deal with
someone who told me "" is not a string as a coworker. That kind of
thing would just piss me off.

 

[Paul Mesken]

The file is fully C89 compliant as far as I can determine.


Well no problems there! Since C89 is the final standard for C.

I agree. IMHO C99 is like the 2.88 MB floppy drive, it exists, is
better than the 1.44 but nobody has one because floppy drives are not
as important as they once were (having CDs, DVDs, etc.) and the 1.44s
are good enough and very widespread

I mean : how many of us are _really_ programming in C? I believe most
of us are actually programming in C++ (or at least using a C++
compiler). C++ is based on C89, not on C99. I don't see C++ changing
its standard to conform to C99 and I don't see that many C99 compilers
for that matter.

I think the question "will it compile and run correctly on a
conforming C++ compiler?" is more important than "is it C99
compliant?".

So, this should get some live in the group ;-)

 

[Mark McIntyre]

The file is fully C89 compliant as far as I can determine.

Its possibly also K&R C compliant. And possibly ISO9000 compliant. So
what?

Well no problems there! Since C89 is the final standard for C.

Okay, I remember now, you're a trolling idiot.

Indeed, this one I have problems with.

I don't. I'm quite happy to think I'll never employ you.

I don't think I could deal with
someone who told me "" is not a string as a coworker. That kind of
thing would just piss me off.

Anyone who denies the existence of a published ISO standard is IMHO
neither a programmer nor a professional, and minor disagreements about
whether nothing is a string or not pale into insignificance.

 

[Mark McIntyre]

I mean : how many of us are _really_ programming in C?

I am.

I believe most of us are actually programming in C++

Nope. At least, not any more than I programme C or VB.

(or at least using a C++ compiler).
Nope.

C++ is based on C89, not on C99. I don't see C++ changing
its standard to conform to C99

Its hardly surprising its based on C89 (if it is) since it was
standardised before C99. And why on earth should it change to match
C99 anyway? Its a different language.

and I don't see that many C99 compilers for that matter.

There's several out there as it happens.

I think the question "will it compile and run correctly on a
conforming C++ compiler?" is more important than "is it C99
compliant?".

Why would anyone want to compile their C code with a C++ compiler?
That makes no sense at all.

So, this should get some live in the group ;-)

Probably not, most people will realise you're trolling, and killfile
you.

 

[Martin Ambuhl]

Well no problems there! Since C89 is the final standard for C.

Huh? Not only is C89 10 years older than the current standard, there is
no reason to think that C99 is "the final standard."

Actually there is an issue with C++; they may cannibalize parts of the
C99 proposal and put it into their standard. However, I can just claim
that this is meant just for C, where there is, of course, no issue.

I believe you are very confused.

 

[Martin Ambuhl]

I mean : how many of us are _really_ programming in C?

Many of us; that's why this newsgroup exists.

> I believe most
of us are actually programming in C++ (or at least using a C++
compiler).

Your belief is actually your own hallucination.

 

[Paul Mesken]

On Fri, 27 May 2005 00:11:32 +0200, in comp.lang.c , Paul Mesken


Why would anyone want to compile their C code with a C++ compiler?
That makes no sense at all.

I could think of a couple of reasons. A certain C++ compiler might be
a very attractive development platform (with neat components for the
GUI, etc.). It is nice if it accepts C code, and a lot of C code will
be accepted by it (there are a couple of pitfalls to watch out for,
though).

Of course, _technically_ that C code would be C++ code but it would
compile and run on both C and C++ compilers.

How's that for portability of C code?

Of course, one could maintain that C++ is a _completely_ different
language than C and that C is not a subset of C++ at all. Indeed, C is
not a subset of C++ but it is about as close as it can get to it.

But let me put it another way then :

Would you make use of C99 constructs of which you know that they won't
compile on a C89/90 compiler? (like compound literals, designated
initializers, etc.).

This would make your code less portable since C99 compilers are by no
means as widespread as C89/90 compilers or C++ compilers that can
accept C89/90 code (barring the few pitfalls, of course).

Of course, one can say that, in the future, the support for C99 will
be as widespread as that of C89/90. But I'm not so sure of it and
we're not living in the future yet.

Probably not, most people will realise you're trolling, and killfile
you.

Well, at least I _believed_ that most C programmers here actually make
use of a C++ compiler. You're far more certain of their behaviour

And I wasn't trolling, I haven't mentioned Assembly (yet ;-)

 

[Paul Mesken]

On 26 May 2005 14:32:50 -0700, in comp.lang.c , (e-mail address removed)
wrote:

Okay, I remember now, you're a trolling idiot.

I think he has a point. Even though there is the newer C99 and perhaps
some more standards in the future, I think it is wisest to stick to
C89/90. C is losing territory to C++ and I don't see C99 becoming as
well supported as C89/90.

I think it's a wiser choice to make sure that the C code will also
compile on a C++ compiler (for future portability).

Of course, I might be terribly misguided but I'm known to respond to
good arguments so let's hear some

 

[Old Wolf]

Nobody has mentioned this explicitly, but the problem is that
C99 contains a header <stdint.h> . So naming your own file
stdint.h is asking for trouble. It doesn't seem inconceivable
that a compiler with both C89 and C99 modes could break when
the user tries to call their own file the same name as a
standard header.

I mean : how many of us are _really_ programming in C?

Posting in comp.lang.c, I think you are going to get a lot
more "Me!" answers to this one, than "not me!"

I believe most of us are actually programming in C++
(or at least using a C++ compiler).

Although I use C and C++, I compile C with a C compiler and
C++ with a C++ compiler ! In fact my compiler automatically
determines based on the file extension.

I don't know of any C++ compilers that do not either
have a C mode, or come packaged with a C compiler.

Can you name one?

I think the question "will it compile and run correctly on a
conforming C++ compiler?" is more important than "is it C99
compliant?".

You're in a minority, at least among posters to this newsgroup.
The most important question is "Does this conform to the
standard that I'm trying to conform to?" I suppose the second-most
question is "Is it worth tring to conform to that standard?"

 

[CBFalconer]

.... snip ...

Well, at least I _believed_ that most C programmers here actually
make use of a C++ compiler. You're far more certain of their
behaviour

They are quite likely to use a compiler that has both C and C++
modes available. That doesn't mean they are compiling with a C++
compiler. Some of those compilers automatically adjust their modes
based on the extension of the source file, thus confusing unaware
users who name their sources as .C (upper case) or .cpp.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Richard Bos]

I agree.

What a surprise.

I mean : how many of us are _really_ programming in C?

*Raises hands*

I believe most of us are actually programming in C++ (or at least
using a C++ compiler).

I don't know about "most of us", but it's not true in my case, anyway.

Richard

 

[Keith Thompson]

1. Older Windows compilers do not support "%llu" but instead use
"%I64u". I have written up a file named "stdint.h" that you can find
here:

[ Snip! ]

which solves the problem for most platforms. Instead of the platform
dependent "%llu" or "%I64u" you would write:

"%" PRINTF_INT64_MODIFIER "u"

You do realise that this makes your header incompatible with the ISO C99
Standard?

Which matters what to who?

If nothing else, the C99 standard provides guidance for extensions in
C90 implementations. The C99 standard header <stdint.h> provides a
number of declarations that can be quite useful even for C90 code. If
an implementer wants to provide these declarations as an extension, or
if a programmer wants them as part of a program, it makes sense to do
so in a header file called "stdint.h". Writing your own "stdint.h"
header with incompatible declarations will cause confusion, which is
trivially avoided by changing the name of the header. (I'm not sure
why you'd want to call it "stdint.h" anyway, since it's not standard.)