Date: Wed, 22 Sep 2021 19:30:08 +0000
On Wed, 22 Sep 2021, Jorg Brown via Liaison wrote:
> When the new type int16_t was introduced, we did not force printf users to
> write "%w16" to use it. Instead, it naturally up-converts to "int", as
> part of parameter-passing conventions to printf, because integral
> parameters are automatically converted to at least "int" when using a
> parameter of type "...", and the standard guarantees <
But that conversion to int is a legacy of K&R C, from before function
prototypes, and arises as a consequence of int16_t being a typedef to some
existing kind of type. I think for current C it's arguably more natural
that there are no such promotions for function arguments (as indicated in
DR#206 for all new floating types).
> Likewise, I don't see any benefit from not automatically converting
> lesser-precision binary floating-point types to "double", as currently
> happens with "float". Whatever minor processing power is required to
Such a promotion in the caller would prevent a called variadic function
from knowing whether the _Float16 passed in variable arguments was a
signaling NaN, for example. (In the absence of such a promotion, whether
the called function can know that depends on the implementation-defined
choice of whether argument passing without change of floating-point format
is a convertFormat or copy operation.)
> When the new type int16_t was introduced, we did not force printf users to
> write "%w16" to use it. Instead, it naturally up-converts to "int", as
> part of parameter-passing conventions to printf, because integral
> parameters are automatically converted to at least "int" when using a
> parameter of type "...", and the standard guarantees <
But that conversion to int is a legacy of K&R C, from before function
prototypes, and arises as a consequence of int16_t being a typedef to some
existing kind of type. I think for current C it's arguably more natural
that there are no such promotions for function arguments (as indicated in
DR#206 for all new floating types).
> Likewise, I don't see any benefit from not automatically converting
> lesser-precision binary floating-point types to "double", as currently
> happens with "float". Whatever minor processing power is required to
Such a promotion in the caller would prevent a called variadic function
from knowing whether the _Float16 passed in variable arguments was a
signaling NaN, for example. (In the absence of such a promotion, whether
the called function can know that depends on the implementation-defined
choice of whether argument passing without change of floating-point format
is a convertFormat or copy operation.)
-- Joseph S. Myers joseph_at_[hidden]
Received on 2021-09-22 14:30:19