Print a short instead of an int... ? What's up with "%hd"?

[Martin Wells]

When passing arguments to a VAL function, all integer types are
promoted, and floats become doubles. Therefore, signed short will be
promoted to signed int. Therefore I can't see any reason why you'd
have:

printf( "%hd", my_short);

instead of:

printf( "%d", my_short);
Martin

[James Kuyper Jr.]

Martin Wells wrote:

When passing arguments to a VAL function, all integer types are
promoted, and floats become doubles. Therefore, signed short will be
promoted to signed int. Therefore I can't see any reason why you'd
have:

printf( "%hd", my_short);

instead of:

printf( "%d", my_short);

I believe that the purpose is to allow the use of the same format string
for printf() and scanf(). The 'h' adds nothing during the printing
process, but makes a difference in the scanning process.

[Kenneth Brody]

"James Kuyper Jr." wrote:

>
Martin Wells wrote:

When passing arguments to a VAL function, all integer types are
promoted, and floats become doubles. Therefore, signed short will be
promoted to signed int. Therefore I can't see any reason why you'd
have:

printf( "%hd", my_short);

instead of:

printf( "%d", my_short);

I believe that the purpose is to allow the use of the same format string
for printf() and scanf(). The 'h' adds nothing during the printing
process, but makes a difference in the scanning process.

It could make a difference. Consider "%hx" when passed (short)-1,
which on my system prints "ffff", whereas "%x" prints "ffffffff".

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Martin Wells]

Kenneth:

It could make a difference. Consider "%hx" when passed (short)-1,
which on my system prints "ffff", whereas "%x" prints "ffffffff".

OK I can see how the following are true:

(unsigned)(shor t)-1 == UINT_MAX (maybe 0xffff)
(short unsigned)(short )-1 == USHRT_MAX (maybe 0xffffffff)

....but is it not undefined behaviour to supply printf with a signed
integer type when it expects an unsigned integer type, or vice versa?

If I wanted to print the max value of an unsigned short (without using
USHRT_MAX of course), then I'd go with:

printf("%u",(un signed)(short unsigned)-1)

Martin

[Old Wolf]

On Oct 23, 3:32 am, Kenneth Brody <kenbr...@spamc op.netwrote:

"James Kuyper Jr." wrote:

I believe that the purpose is to allow the use of the same format string
for printf() and scanf(). The 'h' adds nothing during the printing
process, but makes a difference in the scanning process.

It could make a difference. Consider "%hx" when passed (short)-1,
which on my system prints "ffff", whereas "%x" prints "ffffffff".

Well, you caused undefined behaviour by passing a
signed value. James' comment should be read as saying
it makes no difference to conforming code!

The %hx could in theory allow the compiler to optimize
more, as the printf implementation has the option of
discarding 2 of the 4 bytes read (say) before processing
them.

[Kenneth Brody]

Old Wolf wrote:

>
On Oct 23, 3:32 am, Kenneth Brody <kenbr...@spamc op.netwrote:

"James Kuyper Jr." wrote:

I believe that the purpose is to allow the use of the same format string
for printf() and scanf(). The 'h' adds nothing during the printing
process, but makes a difference in the scanning process.

It could make a difference. Consider "%hx" when passed (short)-1,
which on my system prints "ffff", whereas "%x" prints "ffffffff".

Well, you caused undefined behaviour by passing a
signed value. James' comment should be read as saying
it makes no difference to conforming code!

You are, of course, correct. I hadn't thought about it before,
but it makes perfect sense that %x takes an unsigned value.
(After all, I would want something like "8000" to display, and
not "-7fff".)

The %hx could in theory allow the compiler to optimize
more, as the printf implementation has the option of
discarding 2 of the 4 bytes read (say) before processing
them.

What does the standard say about a varadic function which gets
passed an int but reads it as short? Given that the standard
requires that (in this instance) a short be promoted to int
anyway, does passing an int invoke UB?

On a system with 16-bit short and 32-bit int, does this invoke
UB?

printf("%hd\n", 65536);

My system displays zero, but "gives you the output you expect"
is allowed under UB. :-)

Section 7.19.6.1p7 seems to allow it:

h Specifies that a following d, i, o, u, x, or X conversion
specifier applies to a short int or unsigned short int
argument (the argument will have been promoted according
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^
to the integer promotions, but its value shall be
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^
converted to short int or unsigned short int before
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^
printing); or that a following n conversion specifier
^^^^^^^^
applies to a pointer to a short int argument.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Old Wolf]

On Oct 24, 3:04 am, Kenneth Brody <kenbr...@spamc op.netwrote:

On a system with 16-bit short and 32-bit int, does this invoke
UB?

printf("%hd\n", 65536);

I would think so, but a more interesting question
is whether this invokes UB:
printf("%hd\n", 0);

We've had this discussion at least once before (in
fact, I initiated it one time). I don't recall the
conclusion however :)

[Dik T. Winter]

In article <11************ **********@q5g2 000prf.googlegr oups.comOld Wolf <ol*****@inspir e.net.nzwrites:

On Oct 23, 3:32 am, Kenneth Brody <kenbr...@spamc op.netwrote:

....

It could make a difference. Consider "%hx" when passed (short)-1,
which on my system prints "ffff", whereas "%x" prints "ffffffff".

Well, you caused undefined behaviour by passing a
signed value. James' comment should be read as saying
it makes no difference to conforming code!

Yes, even (unsigned short)2 passed for "%hx" causes undefined behaviour,
when int and short are not essentially the same. So when passing
an "unsigned short", you should cast it to an "unsigned int". Ah, I
like those integer promotion rules. The only arguments types you can
reliably pass to "%x" are unsigned int and longer.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[pete]

Dik T. Winter wrote:

The only arguments types you can
reliably pass to "%x" are unsigned int and longer.

What is reliable about using a longer type than unsigned,
with "%x"?

--
pete

[Charlie Gordon]

"Dik T. Winter" <Di********@cwi .nla écrit dans le message de news:
Jq********@cwi. nl...

In article <11************ **********@q5g2 000prf.googlegr oups.comOld Wolf
<ol*****@inspir e.net.nzwrites:

On Oct 23, 3:32 am, Kenneth Brody <kenbr...@spamc op.netwrote:

...

It could make a difference. Consider "%hx" when passed (short)-1,
which on my system prints "ffff", whereas "%x" prints "ffffffff".

Well, you caused undefined behaviour by passing a
signed value. James' comment should be read as saying
it makes no difference to conforming code!

Yes, even (unsigned short)2 passed for "%hx" causes undefined behaviour,
when int and short are not essentially the same. So when passing
an "unsigned short", you should cast it to an "unsigned int". Ah, I
like those integer promotion rules. The only arguments types you can
reliably pass to "%x" are unsigned int and longer.

It may well be the case under the current wording of the standard, but I
cannot believe it be the intent of the Commitee. It would take an
inordinate amount of bad faith to come up with an implementation that shows
unexpected behaviour for such a case. It would cause enough portability
problems for so many programs to be adequately qualified as *broken*. There
is nothing wrong with passing an int or shorter type for %x format. Passing
anything larger (or longer) is wrong.

--
Chqrlie.