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


Groups > comp.lang.c > #161872

Re: #include <stdint.h>

From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.lang.c
Subject Re: #include <stdint.h>
Date 2021-07-11 02:49 -0700
Organization A noiseless patient Spider
Message-ID <86sg0l6uza.fsf@linuxsc.com> (permalink)
References <sa5vrs$7d3$1@dont-email.me> <87wnqxxoe3.fsf@nosuchdomain.example.com> <86bl7vb24m.fsf@linuxsc.com> <874kdnw20s.fsf@nosuchdomain.example.com>

Show all headers | View raw


Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [... on printing various integer types ...]
>>
>>> Using the macros:
>>>
>>> #include <stdio.h>
>>> // #include <stdint.h>
>>> #include <inttypes.h>
>>> #include <limits.h>
>>>
>>> int main(void) {
>>>     printf("INT_MAX : %d\n", INT_MAX);
>>>     printf("INT_MIN : %d\n", INT_MIN);
>>>     printf("LONG_MAX : %ld\n", LONG_MAX);
>>>     printf("LONG_MIN : %ld\n", LONG_MIN);
>>>     printf("UINT_MAX : %u\n", UINT_MAX);
>>>     printf("ULONG_MAX : %lu\n", ULONG_MAX);
>>>     printf("USHRT_MAX : %u\n", (unsigned)USHRT_MAX);
>>
>> The cast in the last line is not needed.
>>
>>>     printf("\nFrom stdint.h: \n");
>>>     printf("INT8_MAX : %" PRId8 "\n", INT8_MAX);
>>>     printf("INT16_MAX : %" PRId16 "\n", INT16_MAX);
>>>     printf("INT32_MAX : %" PRId32 "\n", INT32_MAX);
>>>     printf("INT64_MAX : %" PRId64 "\n", INT64_MAX);
>>>     printf("UINT8_MAX : %" PRIu8 "\n", UINT16_MAX);
>>>     printf("UINT16_MAX : %" PRIu16 "\n", UINT16_MAX);
>>>     printf("UINT32_MAX : %" PRIu32 "\n", UINT32_MAX);
>>>     printf("UINT64_MAX : %" PRIu64 "\n", UINT64_MAX);
>>> }
>>>
>>> Most of the casts in your original program are unnecessary, since
>>> the expressions are already of the type you were casting them to.
>>> But unsigned short could promote either to signed int or to
>>> unsigned int, depending on their ranges, so converting to unsigned
>>> and using "%u" is appropriate.  In general, when passed to a
>>> variadic function like printf, an argument of an integer type
>>> narrower than int is promoted to int if type's range fits in int,
>>> to unsigned int otherwise.
>>
>> The description of how type promotion works is right, however a
>> cast is still not needed there.  The reason is that values given
>> as variadic arguments are allowed to be the corresponding signed
>> or unsigned version of the type used to get the value, and that
>> will work as long as the value is in the set of values common to
>> both types.  If an unsigned short promotes to int, then its value
>> is guaranteed to be in the set of values representable by both
>> int and unsigned int, and hence using %u for an uncasted unsigned
>> short is always safe.
>
> My reading of the standard is that that's certainly the intent, but
> it's not quite stated explicitly.
>
> N1570 6.5.2.2 makes a similar guarantee for calls to a function defined
> without a prototype.
>
> 7.16.1.1 makes the same guarantee for arguments to the va_arg macro,
> which makes it clear that printf("%u\n", 1) is *supposed* to work, but I
> don't see a guarantee that the call itself (which happens before va_arg
> is invoked -- assuming printf even uses va_arg) has defined behavior.
>
> Or I'm missing something.

I wrote a long reply to Ben Bacarisse in this same thread, you
may want to read that reply in addition to what I write here.

Basically the question boils down to what is meant by the
somewhat vague phrase "the correct type".  I believe that phrase
is meant to refer to the rules of 7.16.1.1.  If you want to say
there's an ambiguity about what is meant, certainly I could agree
with that.  For purposes of posting in comp.lang.c, my usual rule
is to judge the language according to what meaning is intended,
and since here we are in agreement about what is intended here we
are not in conflict.  Whether the C standard "actually says" that
the va_arg rules apply to *printf functions is, I think, not
an answerable question, and in any case not really a useful
question for purposes of comp.lang.c.  I am glad we agree about
what rule is intended, and IMO that is really all that matters
for the present discussion.

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


Thread

#include <stdint.h> SIMON <invalid@invalid.invalid> - 2021-06-13 23:08 +0100
  Re: #include <stdint.h> Bart <bc@freeuk.com> - 2021-06-13 23:27 +0100
    Re: #include <stdint.h> Bart <bc@freeuk.com> - 2021-06-13 23:57 +0100
      Re: #include <stdint.h> Philipp Klaus Krause <pkk@spth.de> - 2021-06-14 09:03 +0200
        Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-14 01:23 -0700
          Re: #include <stdint.h> Philipp Klaus Krause <pkk@spth.de> - 2021-06-14 12:31 +0200
        Re: #include <stdint.h> Bart <bc@freeuk.com> - 2021-06-14 11:54 +0100
  Re: #include <stdint.h> James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-13 18:34 -0400
  Re: #include <stdint.h> Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-13 23:34 +0100
  Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-13 17:48 -0700
    Re: #include <stdint.h> Philipp Klaus Krause <pkk@spth.de> - 2021-06-14 09:09 +0200
      Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-14 01:24 -0700
        Re: #include <stdint.h> Philipp Klaus Krause <pkk@spth.de> - 2021-06-14 12:30 +0200
    Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-24 10:31 -0700
      Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 11:28 -0700
        Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 02:49 -0700
          Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-11 15:30 -0700
            Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-16 03:33 -0700
              Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-16 12:31 -0700
                Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-30 07:07 -0700
                Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-30 08:42 -0700
                Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 03:55 -0700
                Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-06 07:06 -0700
                Re: #include <stdint.h> James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-06 11:47 -0400
        Re: #include <stdint.h> Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-10-06 09:35 -0700
          Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-06 10:06 -0700
          Re: #include <stdint.h> James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-06 17:40 -0400
            Re: #include <stdint.h> Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 22:14 +0000
              Re: #include <stdint.h> James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-06 20:06 -0400
                Re: #include <stdint.h> Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-07 02:15 +0000
      Re: #include <stdint.h> Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-24 22:34 +0100
        Re: #include <stdint.h> Öö Tiib <ootiib@hot.ee> - 2021-06-24 15:01 -0700
          Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 15:26 -0700
        Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 02:14 -0700

csiph-web