Is it dangerous to promote types in printf arguments?

Question

My questions stem from trying to use printf to log things when trying to build for multiple bit-depth platforms (32/64 for example).

A problem that keeps rearing its ugl

Answer 1

bools/_Bools, chars and shorts are first converted into int (if this conversion preserves the value, else into unsigned int) when passed to variadic functions like printf(). Similarly floats get converted into doubles.

So, if you pass something smaller than int, printf() will grab the whole (unsigned) int without any problems (other than if the passed value is actually an unsigned int and you're printing it with %d instead of %u, you get undefined behavior).

Other types, AFAIR, do not undergo such conversions.

This line:

print (" my int: %ld\n", (long)myInt);

isn't buying you anything over this line:

printf(" my int: %d\n", myInt);

Both are valid and the result will be practically identical. The only difference is that the former might result in bigger code and longer execution time (if sizeof(long) >= sizeof(int)).

Answer 2

1. The arguments are passed in the stack, which has a fixed width (32 or 64) bits per entry. The compiler 'casts' the integers, chars, shorts to the native width of the architecture or in the case of a double (or long long) at 32 architecture, it allocates two slots from the stack. The "padding" is done either with zeroes, or the sign bit of the variable is copied to the remaining bits. (called sign bit extension)

2. One downside in promoting to 64 bits is the lack of compatibility in embedded systems, which do not often provide 64-bit printing. Also it means in 32-bit system some performance penalty as the top 32-bits are always passed and converted (there's a 64 bit wide division by 10 involved) without any real use. The bigger problem however, falls in to the domain of software engineering: does a "future compatible" log give a false hope that also all computation and all the input to the system works in 64-bit mode on 32-bit systems.

(long) in 32-bit architectures doesn't mean 64 bit. That is notated with (long long).

Answer 3

Regarding printf: In the case you sited, "%d" must, by specification, handle the platform-defined 'int' data type. It doesn't matter whether it is 32bits, 64bits, or 128bit linear AS/400 value. If you want to promote the value to a larger field type (and match that promotion with the related format string particle) you're certainly free to do so,

int a=0;
printf("%ld", (long)a);

is certainly defined behavior using promotion.

I think the real crux of your question comes in cases like the following, and whether forcing promotion can "solve" any problems that arise. For example:

char ch = 'a';
printf("%d", ch);

or what about:

char ch = 'a';
printf("%ld", (long)ch);

or maybe this (which is the real condition you seem to be trying to avoid):

char ch = 'a';
printf("%ld", ch);

The first of these will work, but only because the minimum size of anything stack-pushed on a va-arg list is the platform-size of an int. The compiler will auto-promote the value to an int for you. Since "%d" expects a platform int all will appear well.

The second will work always and is fully supported. There is a clear and defined promotion from char to long. Even if long is 64bits (or larger) it will still work.

The third is UB all the way. printf is looking for a long and will be presented with only bytes for an int. If this seems to "work" on your platform, then check your platform width for int and long. It is likely "working" only because your platform long and int are the same bit-width. It makes for fun surprises when porting the code to platforms where they are not, and since it is pushed through a va-arg, you won't see it until real different widths come in to play.

All of that being said, now throw an actual address to something (anything, really) such as that required by scanf and we're looking at something entirely different.

int val;
sscanf("%ld",&val);

This is a seg-fault waiting to happen. Just like above, you'll never know it if your platform long and platform int are the same width. Take this code to a box where long and int are different sizes and prep yourself for a gdb-load of the ensuing core file.

Answer 4

You said:

A problem that keeps rearing its ugly head is trying to print ints on multiple architectures

Is it dangerous to try and get in front of type issues by passing in values that are not of that type size, yes. Thats why the compiler warns you. The notion of portability which seems to be causing you problems is not designed to make printf happy.

Its designed to make your program run and not crash on multiple architectures. If you have platform specific code you should use #ifdef macros to work around it.

Otherwise you are rolling the dice trying to layer over memory level type conversion.

printf is a convenience not a type conversion methodology.

It seems you are focused on ints - which you will probably get away with. But in general I would not rely on a technique like this.