Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #402439

Re: Dodging undefined behaviour in printf

Show all headers | View raw

On 2026-09-27 12:12, highcrew wrote:
> Dear c.l.c.
> 
> I'm trying to refine my knowledge on the topic of type promotions, and 
> now I know how promotion is implied when passing arguments to a function 
> whose prototype is missing argument definition, or to functions having 
> variadic argument list.

"The ellipsis notation in a variadic function declarator (6.7.7.4)
causes argument type conversion to stop after the last declared
parameter, if present. The integer promotions are performed on each
trailing argument, and trailing arguments that have type float are
promoted to double. These are called the _default argument promotions_.
No other conversions are performed implicitly." (6.5.3.3p6)

The term "default argument promotions" is in italics, and ISO convention
indicating that the term is a special piece of jargon whose definition
is provided by that sentence.

> So I was wondering about the following:
> 
> 	unsigned short x = value;
> 	printf("%x", x);
> 
> Assuming that sizeof(unsigned short) < sizeof(int), I would guess that x 
> is promoted to signed int, which is however the wrong type, as it should 
> be unsigned int.

"If the original type is not a bit-precise integer type (6.2.5): if an
int can represent all values of the original type (as restricted by the
width, for a bit-field), the value is converted to an int;50) otherwise,
it is converted to an unsigned int. These are called the _integer
promotions_. All other types are unchanged by the integer promotions."
(6.3.2.1p2).
As before, this sentence serves as the official definition of the term
"integer promotions".

Note that what matters is not sizeof(), but the range of representable
values. It's a minor distinction, of importance mainly because the
standard allows types to have an arbitrarily large number of padding
bits. But the correct statement is that if USHRT_MAX < INT_MAX, the
value of x will be promoted to an int. Implementations are allowed to
have SHRT_MAX == INT_MAX, in which case USHRT_MAX > INT_MAX, in which
case x will remain unsigned short. Note that, in either case, the
promoted value will be the same as the original value.

"For signed types ... Each bit that is a value bit shall have the same
value as the same bit in the object representation of the corresponding
unsigned type." (6.2.6.2p2)

So the way in which the value is represented will be unchanged.

...> Would this be a problem? Am I supposed to explicitly cast x to
(unsigned
> int) when passing it to printf?
> 
> I find it interesting that the problem is not a problem on architectures 
> where sizeof(unsigned short) == sizeof(unsigned int) -- if I will ever 
> find such a thing.
> 
> How about %hx then?

%x is intended for unsigned int arguments, %hx expects the corresponding
argument to be unsigned short.

However,
"fprintf shall behave as if it uses va_arg with a type argument naming
the type resulting from applying the default argument promotions to the
type corresponding to the conversion specification and then converting
the result of the va_arg expansion to the type corresponding to the
conversion specification." (7.24.6.2p9)

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Dodging undefined behaviour in printf highcrew <high.crew3868@fastmail.com> - 2026-09-27 18:12 +0200
  Re: Dodging undefined behaviour in printf Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-28 01:47 +0800
  Re: Dodging undefined behaviour in printf Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-27 10:48 -0700
  Re: Dodging undefined behaviour in printf James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-27 20:30 -0400
  Re: Dodging undefined behaviour in printf David Brown <david.brown@hesbynett.no> - 2026-09-28 09:50 +0200
  Re: Dodging undefined behaviour in printf "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-30 13:05 -0700

csiph-web