Portability of printf formats

[bewing]

I am editing some code that uses "%I64d" and other I64 formats for printing qwords. I understand that I64 is mostly/entirely win32-specific. I want to remove all the 'I64's and replace them with 'll's. %lld works on MSVC5, and I assume it works on all versions of MSVC higher than 5. But the code DOES need to be portable across many compilers.

In some other programmers' code that I looked at, I noticed that they have special "os-dependent" I64 format strings #defined for win32 compilers. Why? Are there some compilers that do not accept "%lld" or do not print it correctly? Or were those other programmers being unreasonably cautious?
I think I understand that the 'll' format was officially specified in the ISO C'99 standard, so any compiler <10 years old "must" support it? Do any of you know some that don't?

[Brynet-Inc]

It is a C99 thing, that's true.

Some older BSD derivatives used %q for quadwords, but typically %lld or %llu is the portable choice.

See: http://www.opengroup.org/onlinepubs/009 ... rintf.html

Do systems exist that are unable to print 64-bit values? most definitely.. but they'll be old.

[Solar]

You have no guarantee that %lld will refer to a 64-bit integer. It will refer to a "long long", but beyond that, all bets are off.

For portable printf() formatting strings, C99 offers <inttypes.h>. It has printf() and scanf() macros for each of the types defined in <stdint.h>. So, for example, you can print a int64_t with:

printf( "%" PRId64 "\n", x );

Of course, this works only if your implementation (i.e., compiler / library) does support 64-bit values. Which is, after all, kind of a precondition.

[Brynet-Inc]

You have no guarantee that %lld will refer to a 64-bit integer. It will refer to a "long long", but beyond that, all bets are off.

For portable printf() formatting strings, C99 offers <inttypes.h>. It has printf() and scanf() macros for each of the types defined in <stdint.h>. So, for example, you can print a int64_t with:

printf( "%" PRId64 "\n", x );

Of course, this works only if your implementation (i.e., compiler / library) does support 64-bit values. Which is, after all, kind of a precondition.

I guess I'll have to agree for the most part..

PRId64 does translate to %lld on every system I've seen..

I was talking about this to a friend the other day, and long long is guaranteed to be at least 64bits.. but we've yet found a system with a larger size.

There may be some weird systems out there with 128bit types, agreed, but they are likely custom prefixed, I do doubt that they increase the size of the long long type yet.. risking portability issues.

[Solar]

There I was, intending to shoot down your argument of long long being "guaranteed" to be >64 bits with a select quote from the language standard stating that this isn't so - because that's how I remembered, that the standard only guarantees that long long >= long.

But lo, you're absolutely right. "long long" is guaranteed to be 64 bits or larger... you never stop learning.

[CodeCat]

Speaking of the sizes of various C data types, is there any REAL reason for not adopting standardised fixed sizes? AFAIK Java does this (byte = 1, short = 2, int = 4, long = 8), and the default sizes on x86-64 bit platforms (on Linux anyway) are the same as the Java sizes. So besides the fact that some people would be angry if they did it now, is there really a reason why C couldn't be standardised the same way?

[Brynet-Inc]

Speaking of the sizes of various C data types, is there any REAL reason for not adopting standardised fixed sizes? AFAIK Java does this (byte = 1, short = 2, int = 4, long = , and the default sizes on x86-64 bit platforms (on Linux anyway) are the same as the Java sizes. So besides the fact that some people would be angry if they did it now, is there really a reason why C couldn't be standardised the same way?

And yet another person demonstrates their unawareness of stdint types.

[quok]

There I was, intending to shoot down your argument of long long being "guaranteed" to be >64 bits with a select quote from the language standard stating that this isn't so - because that's how I remembered, that the standard only guarantees that long long >= long.

But lo, you're absolutely right. "long long" is guaranteed to be 64 bits or larger... you never stop learning.

Heh, I started reading this and got no farther than "There I was, intending to shoot down your argument..." when I thought: pwned.

[bewing]

The problem with stdint types is that they have to be INCLUDED, and anyone on any platform can mess with the include file. So it isn't truly standardized. The only way for it to truly be standardized in my book is if you can't possibly turn it off, and you don't do anything at all to "turn it on".

And I basically agree that the proper way to design a language is for all the types to be a precise standard bitsize, except for int -- and int should never ever be used in any API function. API functions should always use a fixed-bitsize type for all arguments, with the bitsize chosen to be "unreasonably large" for the current state of technology.

[CodeCat]

And yet another person demonstrates their unawareness of stdint types.

I was very aware of those, thanks. My question was about the standardisation of the intrinstic built-in types rather than having to rely on typedefs in a header.

[Solar]

The problem with stdint types is that they have to be INCLUDED, and anyone on any platform can mess with the include file. So it isn't truly standardized.

Can we please turn off the "Java Advocacy" mode?

Java defines an int to be 32 bit, and unless you hack the VM, that's what you get. C defines an int32_t to be 32 bit, and unless you hack the headers, that's what you get. If your file permissions are so screwed up that any Joe Average User has write access to the system headers, that's not the problem of the language, is it?

Java was designed and implemented by Sun, in the early nineties. No installed code base, no backward compatibility concerns, and a single company pulling the strings.

C was designed and implemented by a geek at Bell Labs, twenty years earlier, released "into the wild" early on, and had a rich installed code base (the whole Unix OS, among others) before any ANSI / ISO standard committee began to take an interest.

Believe me, Java won't look pretty in twenty years, either.

[DeletedAccount]

Believe me, Java won't look pretty in twenty years, either.

I am not a Java advocate or C# advocate , but Java still will have a place not because Java is completely original , but the implementation was good . The original idea was from Writh I guess. Even C is not so original .

Regards
Sandeep

[Solar]

Contrary to popular propaganda, I'm pretty certain C++ will still be around, too...

[Brynet-Inc]

Contrary to popular propaganda, I'm pretty certain C++ will still be around, too...

..and C, as long as there are Unix hobbyists.. C will live on.