What changes do I need to make to get the correct values for the last
two items in this program:

> #include <stdio.h>
> #include <stdint.h>
> #include <limits.h>
>
> int main()
> {
> printf("INT_MAX : %d\n", INT_MAX);
> printf("INT_MIN : %d\n", INT_MIN);
> printf("LONG_MAX : %ld\n", (long)LONG_MAX);
> printf("LONG_MIN : %ld\n", (long)LONG_MIN);
> printf("UINT_MAX : %u\n", (unsigned int)UINT_MAX);
> printf("ULONG_MAX : %lu\n", (unsigned long)ULONG_MAX);
> printf("USHRT_MAX : %d\n", (unsigned short)USHRT_MAX);
> printf("\nFrom stdint.h: \n");
> printf("INT8_MAX : %d\n", INT8_MAX);
> printf("INT16_MAX : %d\n", INT16_MAX);
> printf("INT32_MAX : %d\n", INT32_MAX);
> printf("INT64_MAX : %lld\n", INT64_MAX);
> printf("UINT8_MAX : %d\n", UINT16_MAX);
> printf("UINT16_MAX : %d\n", UINT16_MAX);
> printf("UINT32_MAX : %d\n", UINT32_MAX);
> printf("UINT64_MAX : %lld\n", UINT64_MAX);
> }

I am using Windows 10 64 bit machine and I have tried GCC64 bit and
Visual Studio 2019 64 bit. The last two results are just ( -1 ). this is clearly over/underflow somehow so what changes are necessary.

I was in the opinion that stdint.h is cross-compiler/cross- platform
compliant.

On 13/06/2021 23:08, SIMON wrote:
> What changes do I need to make to get the correct values for the last
> two items in this program:
>
>> #include <stdio.h>
>> #include <stdint.h>
>> #include <limits.h>
>>
>> int main()
>> {
>>  printf("INT_MAX : %d\n", INT_MAX);
>>  printf("INT_MIN : %d\n", INT_MIN);
>>  printf("LONG_MAX : %ld\n", (long)LONG_MAX);
>>  printf("LONG_MIN : %ld\n", (long)LONG_MIN);
>>  printf("UINT_MAX : %u\n", (unsigned int)UINT_MAX);
>>  printf("ULONG_MAX : %lu\n", (unsigned long)ULONG_MAX);
>>  printf("USHRT_MAX : %d\n", (unsigned short)USHRT_MAX);
>>  printf("\nFrom stdint.h: \n");
>>  printf("INT8_MAX : %d\n", INT8_MAX);
>>  printf("INT16_MAX : %d\n", INT16_MAX);
>>  printf("INT32_MAX : %d\n", INT32_MAX);
>>  printf("INT64_MAX : %lld\n", INT64_MAX);
>>  printf("UINT8_MAX : %d\n", UINT16_MAX);
>>  printf("UINT16_MAX : %d\n", UINT16_MAX);
>>  printf("UINT32_MAX : %d\n", UINT32_MAX);
>>  printf("UINT64_MAX : %lld\n", UINT64_MAX);
>> }
>
> I am using Windows 10 64 bit machine and I have tried GCC64 bit and
> Visual Studio 2019 64 bit. The last two results are just ( -1 ). this is
> clearly over/underflow somehow so what changes are necessary.
>
> I was in the opinion that stdint.h is cross-compiler/cross- platform
> compliant.

Try %ud and %ulld.

On 6/13/21 6:08 PM, SIMON wrote:
> What changes do I need to make to get the correct values for the last
> two items in this program:
>
>> #include <stdio.h>
>> #include <stdint.h>
>> #include <limits.h>

#include <inttypes.h>

>> int main()
>> {
>> printf("INT_MAX : %d\n", INT_MAX);
>> printf("INT_MIN : %d\n", INT_MIN);
>> printf("LONG_MAX : %ld\n", (long)LONG_MAX);
>> printf("LONG_MIN : %ld\n", (long)LONG_MIN);
>> printf("UINT_MAX : %u\n", (unsigned int)UINT_MAX);
>> printf("ULONG_MAX : %lu\n", (unsigned long)ULONG_MAX);
>> printf("USHRT_MAX : %d\n", (unsigned short)USHRT_MAX);
>> printf("\nFrom stdint.h: \n");
>> printf("INT8_MAX : %d\n", INT8_MAX);
>> printf("INT16_MAX : %d\n", INT16_MAX);
>> printf("INT32_MAX : %d\n", INT32_MAX);
>> printf("INT64_MAX : %lld\n", INT64_MAX);
>> printf("UINT8_MAX : %d\n", UINT16_MAX);
>> printf("UINT16_MAX : %d\n", UINT16_MAX);
>> printf("UINT32_MAX : %d\n", UINT32_MAX);
>> printf("UINT64_MAX : %lld\n", UINT64_MAX);

You should not be using the "d" conversion specifier for unsigned types.
You should use "u", "o", "x" or "X" formats.
In general, you should not use explicit length specifiers (such as "h",
"hh", "l", and "ll") for the size-named types - there's no guaranteed
connection between the specifiers and the types. Instead, you should use
the print format macros from <inttypes.h>:

printf("INT8_MAX : %" PRId8 "\n", INT8_MAX);
printf("INT8_MAX : %" PRId16 "\n", INT16_MAX);
printf("INT8_MAX : %" PRId32 "\n", INT32_MAX);
printf("INT8_MAX : %" PRId64 "\n", INT64_MAX);

Assuming that you would actually have chosen the "u" conversion
specifier, you should use the following for the unsigned types. If you
would prefer, for instance, the "x" conversion specifier, change "u" to
"x" in the following macro names:
printf("UINT8_MAX : %" PRIu8 "\n", UINT8_MAX);
printf("UINT8_MAX : %" PRIu16 "\n", UINT16_MAX);
printf("UINT8_MAX : %" PRIu32 "\n", UINT32_MAX);
printf("UINT8_MAX : %" PRIu64 "\n", UINT64_MAX);

>> }
>
> I am using Windows 10 64 bit machine and I have tried GCC64 bit and
> Visual Studio 2019 64 bit. The last two results are just ( -1 ). this is clearly over/underflow somehow so what changes are necessary.
>
> I was in the opinion that stdint.h is cross-compiler/cross- platform
> compliant.

It is, when used correctly - which means, among other things, using the
print macros rather than explicit length specifiers in printf/scanf
family format strings. The exact-sized types are optional, but the
corresponding macros must be #defined and if (and only if) the
corresponding types are supported.
For maximum portability, you should avoid the exact-sized types and use
only int_fastN_t and int_leastN_t types, and only for the values of N
for which support for those types is mandatory: 8, 16, 32, and 64. In
practice, most people can ignore this advice.

SIMON <invalid@invalid.invalid> writes:

> What changes do I need to make to get the correct values for the last
> two items in this program:
>
>> #include <stdio.h>
>> #include <stdint.h>
>> #include <limits.h>
>>
>> int main()
>> {
>> printf("INT_MAX : %d\n", INT_MAX);
>> printf("INT_MIN : %d\n", INT_MIN);
>> printf("LONG_MAX : %ld\n", (long)LONG_MAX);
>> printf("LONG_MIN : %ld\n", (long)LONG_MIN);
>> printf("UINT_MAX : %u\n", (unsigned int)UINT_MAX);
>> printf("ULONG_MAX : %lu\n", (unsigned long)ULONG_MAX);
>> printf("USHRT_MAX : %d\n", (unsigned short)USHRT_MAX);

None of these casts add anything.

(There are also LLONG_MIN/MAX and ULLONG_MAX which you can print using
%lld and %llu.)

>> printf("\nFrom stdint.h: \n");
>> printf("INT8_MAX : %d\n", INT8_MAX);
>> printf("INT16_MAX : %d\n", INT16_MAX);
>> printf("INT32_MAX : %d\n", INT32_MAX);
>> printf("INT64_MAX : %lld\n", INT64_MAX);
>> printf("UINT8_MAX : %d\n", UINT16_MAX);
>> printf("UINT16_MAX : %d\n", UINT16_MAX);
>> printf("UINT32_MAX : %d\n", UINT32_MAX);
>> printf("UINT64_MAX : %lld\n", UINT64_MAX);

All of these types have macros defined in inttypes.h that can be used to
print them. For example

printf("UINT64_MAX : %"PRIu64"\n", UINT64_MAX);

For maximum portability, you can't even assume that %d can be used for
INT32_MAX -- on a system where int is narrower than 32 bits, %d won't
work. Similarly, %d won't necessarily work even for UINT16_MAX. On a
system with a 16-bit int you would have to use %u. But all of these are
"fudges" to some extent.

The last two can be also fudged (for the sort of system you are likely
to be using) like this:

printf("UINT32_MAX : %u\n", UINT32_MAX);
printf("UINT64_MAX : %llu\n", UINT64_MAX);

but really, why fudge it? Use PRIu32 and PRIu64.

--
Ben.

On 13/06/2021 23:27, Bart wrote:
> On 13/06/2021 23:08, SIMON wrote:
>> What changes do I need to make to get the correct values for the last
>> two items in this program:
>>
>>> #include <stdio.h>
>>> #include <stdint.h>
>>> #include <limits.h>
>>>
>>> int main()
>>> {
>>>  printf("INT_MAX : %d\n", INT_MAX);
>>>  printf("INT_MIN : %d\n", INT_MIN);
>>>  printf("LONG_MAX : %ld\n", (long)LONG_MAX);
>>>  printf("LONG_MIN : %ld\n", (long)LONG_MIN);
>>>  printf("UINT_MAX : %u\n", (unsigned int)UINT_MAX);
>>>  printf("ULONG_MAX : %lu\n", (unsigned long)ULONG_MAX);
>>>  printf("USHRT_MAX : %d\n", (unsigned short)USHRT_MAX);
>>>  printf("\nFrom stdint.h: \n");
>>>  printf("INT8_MAX : %d\n", INT8_MAX);
>>>  printf("INT16_MAX : %d\n", INT16_MAX);
>>>  printf("INT32_MAX : %d\n", INT32_MAX);
>>>  printf("INT64_MAX : %lld\n", INT64_MAX);
>>>  printf("UINT8_MAX : %d\n", UINT16_MAX);
>>>  printf("UINT16_MAX : %d\n", UINT16_MAX);
>>>  printf("UINT32_MAX : %d\n", UINT32_MAX);
>>>  printf("UINT64_MAX : %lld\n", UINT64_MAX);
>>> }
>>
>> I am using Windows 10 64 bit machine and I have tried GCC64 bit and
>> Visual Studio 2019 64 bit. The last two results are just ( -1 ). this
>> is clearly over/underflow somehow so what changes are necessary.
>>
>> I was in the opinion that stdint.h is cross-compiler/cross- platform
>> compliant.
>
>
> Try %ud and %ulld.

Huh. They should be %u and %llu (u is because they are unsigned).

Or you can display as hex using %X and $llX.

This should fine if running under Windows. For portable code, you really
need to use an ugly set of macros from stdint.h or inttypes.h, since the
correct formats vary betweeen Windows and Linux (eg. Linux might need
one 'l' rather than two, but I believe 'll' will work too).

If you just want to know the limits, you can also look inside stdint.h.

SIMON <invalid@invalid.invalid> writes:
> What changes do I need to make to get the correct values for the last
> two items in this program:
>
>> #include <stdio.h>
>> #include <stdint.h>
>> #include <limits.h>
>>
>> int main()
>> {
>> printf("INT_MAX : %d\n", INT_MAX);
>> printf("INT_MIN : %d\n", INT_MIN);
>> printf("LONG_MAX : %ld\n", (long)LONG_MAX);
>> printf("LONG_MIN : %ld\n", (long)LONG_MIN);
>> printf("UINT_MAX : %u\n", (unsigned int)UINT_MAX);
>> printf("ULONG_MAX : %lu\n", (unsigned long)ULONG_MAX);
>> printf("USHRT_MAX : %d\n", (unsigned short)USHRT_MAX);
>> printf("\nFrom stdint.h: \n");
>> printf("INT8_MAX : %d\n", INT8_MAX);
>> printf("INT16_MAX : %d\n", INT16_MAX);
>> printf("INT32_MAX : %d\n", INT32_MAX);
>> printf("INT64_MAX : %lld\n", INT64_MAX);
>> printf("UINT8_MAX : %d\n", UINT16_MAX);
>> printf("UINT16_MAX : %d\n", UINT16_MAX);
>> printf("UINT32_MAX : %d\n", UINT32_MAX);
>> printf("UINT64_MAX : %lld\n", UINT64_MAX);
>> }
>
> I am using Windows 10 64 bit machine and I have tried GCC64 bit and
> Visual Studio 2019 64 bit. The last two results are just ( -1 ). this
> is clearly over/underflow somehow so what changes are necessary.
>
> I was in the opinion that stdint.h is cross-compiler/cross- platform
> compliant.

It is -- but none of the exact-width types are guaranteed to exist
(though the 8, 16, 32, and 64 bit ones almost certainly will on typical
systems).

<inttypes.h> provides macros that expand to appropriate format strings.
<inttypes.h> includes <stdint.h>, so you don't need to include both,
though you can.

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);
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.

An alternative, if you don't want to remember or look up all those
macros, is to convert to a type that's known to be wide enough.
long long is guaranteed to be at least 64 bits (and is almost always
exactly 64 bits), so this might be simpler:

#include <stdio.h>
#include <stdint.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);
printf("\nFrom stdint.h : \n");
printf("INT8_MAX : %lld\n", (long long)INT8_MAX);
printf("INT16_MAX : %lld\n", (long long)INT16_MAX);
printf("INT32_MAX : %lld\n", (long long)INT32_MAX);
printf("INT64_MAX : %lld\n", (long long)INT64_MAX);
printf("UINT8_MAX : %llu\n", (unsigned long long)UINT16_MAX);
printf("UINT16_MAX : %llu\n", (unsigned long long)UINT16_MAX);
printf("UINT32_MAX : %llu\n", (unsigned long long)UINT32_MAX);
printf("UINT64_MAX : %llu\n", (unsigned long long)UINT64_MAX);
}

There's some performance cost relative to the type-specific format
macros, but printf itself is far more expensive than a few integer type
conversions.

If you have an integer type that might possibly be wider than long
long (which is unlikely in practice), you can convert to intmax_t
or uintmax_t and use "%jd" or "%ju". That might be overkill if you
don't really need 100% guarantee portability.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Am 14.06.21 um 00:57 schrieb Bart:
>
> This should fine if running under Windows. For portable code, you really
> need to use an ugly set of macros from stdint.h or inttypes.h, since the
> correct formats vary betweeen Windows and Linux (eg. Linux might need
> one 'l' rather than two, but I believe 'll' will work too).

The C23 standard from 2023 has the %w modifier:

printf("UINT64_MAX : %w64u\n", UINT64_MAX);

Philipp

Am 14.06.21 um 02:48 schrieb Keith Thompson:
>
> If you have an integer type that might possibly be wider than long
> long (which is unlikely in practice), you can convert to intmax_t
> or uintmax_t and use "%jd" or "%ju". That might be overkill if you
> don't really need 100% guarantee portability.
>

And there is the real risk of intmax_t being removed from a future
standard, which is very, very unlikely to ever happen to long long.

Philipp

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 14.06.21 um 00:57 schrieb Bart:
>> This should fine if running under Windows. For portable code, you really
>> need to use an ugly set of macros from stdint.h or inttypes.h, since the
>> correct formats vary betweeen Windows and Linux (eg. Linux might need
>> one 'l' rather than two, but I believe 'll' will work too).
>
> The C23 standard from 2023 has the %w modifier:
>
> printf("UINT64_MAX : %w64u\n", UINT64_MAX);

Do you have a source for that? The latest draft I have (N2596,
Dec 11 2020) doesn't mention that.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 14.06.21 um 02:48 schrieb Keith Thompson:
>> If you have an integer type that might possibly be wider than long
>> long (which is unlikely in practice), you can convert to intmax_t
>> or uintmax_t and use "%jd" or "%ju". That might be overkill if you
>> don't really need 100% guarantee portability.
>
> And there is the real risk of intmax_t being removed from a future
> standard, which is very, very unlikely to ever happen to long long.

I doubt that there's much risk of that. I can imagine its semantics
being changed, but removing it would break existing code.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

>> And there is the real risk of intmax_t being removed from a future
>> standard, which is very, very unlikely to ever happen to long long.
>
> I doubt that there's much risk of that. I can imagine its semantics
> being changed, but removing it would break existing code.
>

The problem with intmax_t:
It needs to be the widest type, so it needs to grow when y type is
added. That breaks the ABI.
There was a WG14 straw poll opting for full removal, but no wording had
been proposed at that time, and no wording has come up so far. However,
N2548 has changed some functions to use different types instead:
Functions new in C23 have been changed to use whatever other type was
most appropriate. Older functions have been changed to long long, since
apparently practically intmax_t was the same as long long, so this
change preserves the ABI.

Philipp

>> The C23 standard from 2023 has the %w modifier:
>>
>> printf("UINT64_MAX : %w64u\n", UINT64_MAX);
>
> Do you have a source for that? The latest draft I have (N2596,
> Dec 11 2020) doesn't mention that.

The proposal was N2680, which according to the meeting minutes N2690 is in.

Philipp

On 14/06/2021 08:03, Philipp Klaus Krause wrote:
> Am 14.06.21 um 00:57 schrieb Bart:
>>
>> This should fine if running under Windows. For portable code, you really
>> need to use an ugly set of macros from stdint.h or inttypes.h, since the
>> correct formats vary betweeen Windows and Linux (eg. Linux might need
>> one 'l' rather than two, but I believe 'll' will work too).
>
> The C23 standard from 2023 has the %w modifier:
>
> printf("UINT64_MAX : %w64u\n", UINT64_MAX);
>
> Philipp
>

%w64u is not supported by msvcrt.dll yet.

However why are they still messing about with format codes? One change I
tried with my C compiler was to use a "%?" specifier which adapts itself
to whatever is being printed:

printf("UINT64_MAX/A : %llu\n", UINT64_MAX);
printf("UINT64_MAX/B : %w64u\n", UINT64_MAX);
printf("UINT64_MAX/C : %?\n", UINT64_MAX);

Output is:

UINT64_MAX/A : 18446744073709551615
UINT64_MAX/B : 64u
UINT64_MAX/C : 18446744073709551615

Of course, this is done inside the compiler and is only possible when a
format is a string literal; it does not change the library.

I can use this one format in the OP's program:

printf("INT_MAX : %?\n", INT_MAX);
printf("INT_MIN : %?\n", INT_MIN);
printf("LONG_MAX : %?\n", (long)LONG_MAX);
printf("LONG_MIN : %?\n", (long)LONG_MIN);
printf("UINT_MAX : %?\n", (unsigned int)UINT_MAX);
printf("ULONG_MAX : %?\n", (unsigned long)ULONG_MAX);
printf("USHRT_MAX : %?\n", (unsigned short)USHRT_MAX);
printf("\nFrom stdint.h: \n");
printf("INT8_MAX : %?\n", INT8_MAX);
printf("INT16_MAX : %?\n", INT16_MAX);
printf("INT32_MAX : %?\n", INT32_MAX);
printf("INT64_MAX : %?\n", INT64_MAX);
printf("UINT8_MAX : %?\n", UINT8_MAX); // Fixed FROM UINT16_MAX
printf("UINT16_MAX : %?\n", UINT16_MAX);
printf("UINT32_MAX : %?\n", UINT32_MAX);
printf("UINT64_MAX : %?\n", UINT64_MAX);

And the output is:

INT_MAX : 2147483647
INT_MIN : -2147483648
LONG_MAX : 2147483647
LONG_MIN : -2147483648
UINT_MAX : 4294967295
ULONG_MAX : 4294967295
USHRT_MAX : 65535

From stdint.h:
INT8_MAX : 127
INT16_MAX : 32767
INT32_MAX : 2147483647
INT64_MAX : 9223372036854775807
UINT8_MAX : 255
UINT16_MAX : 65535
UINT32_MAX : 4294967295
UINT64_MAX : 18446744073709551615

Who, in 2023 and beyond, still wants to muck around with format codes?!

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.

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.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [... on printing various integer types ...]
<cut>
>> printf("USHRT_MAX : %u\n", (unsigned)USHRT_MAX);
>
> The cast in the last line is not needed.
<cut>
> 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.

It's safe (in practical terms) but 7.21.6.1 paragraph 8 says of the 'u'
conversion specifier:

"o,u,x,X The unsigned int argument is..."

and, later, paragraph 9 says

"... If any argument is not the correct type for the corresponding
conversion specification, the behavior is undefined."

So I am left wondering how one can know that int (the promoted type when
no cast is used) is "the correct type" for the 'u' conversion
specification.

--
Ben.

On Friday, 25 June 2021 at 00:34:58 UTC+3, Ben Bacarisse wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
>
> > Keith Thompson <Keith.S.T...@gmail.com> writes:
> >
> > [... on printing various integer types ...]
> <cut>
> >> printf("USHRT_MAX : %u\n", (unsigned)USHRT_MAX);
> >
> > The cast in the last line is not needed.
> <cut>
> > 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.
> It's safe (in practical terms) but 7.21.6.1 paragraph 8 says of the 'u'
> conversion specifier:
>
> "o,u,x,X The unsigned int argument is..."
>
> and, later, paragraph 9 says
>
> "... If any argument is not the correct type for the corresponding
> conversion specification, the behavior is undefined."
>
> So I am left wondering how one can know that int (the promoted type when
> no cast is used) is "the correct type" for the 'u' conversion
> specification.

Yes it is strange. IIRC the constant USHRT_MAX may be of type
signed int or unsigned int but can not be of type unsigned short.

Öö Tiib <ootiib@hot.ee> writes:
> On Friday, 25 June 2021 at 00:34:58 UTC+3, Ben Bacarisse wrote:
>> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
>> > Keith Thompson <Keith.S.T...@gmail.com> writes:
>> >
>> > [... on printing various integer types ...]
>> <cut>
>> >> printf("USHRT_MAX : %u\n", (unsigned)USHRT_MAX);
>> >
>> > The cast in the last line is not needed.
>> <cut>
>> > 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.
>> It's safe (in practical terms) but 7.21.6.1 paragraph 8 says of the 'u'
>> conversion specifier:
>>
>> "o,u,x,X The unsigned int argument is..."
>>
>> and, later, paragraph 9 says
>>
>> "... If any argument is not the correct type for the corresponding
>> conversion specification, the behavior is undefined."
>>
>> So I am left wondering how one can know that int (the promoted type when
>> no cast is used) is "the correct type" for the 'u' conversion
>> specification.
>
> Yes it is strange. IIRC the constant USHRT_MAX may be of type
> signed int or unsigned int but can not be of type unsigned short.

Correct. Which means that if you want to print the value of USHRT_MAX
safely, you can do:

printf("USHRT_MAX = %u\n", (unsigned)USHRT_MAX);

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [... on printing various integer types ...]
>
> <cut>
>
>>> printf("USHRT_MAX : %u\n", (unsigned)USHRT_MAX);
>>
>> The cast in the last line is not needed.
>
> <cut>
>
>> 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.
>
> It's safe (in practical terms) but 7.21.6.1 paragraph 8 says of the
> 'u' conversion specifier:
>
> "o,u,x,X The unsigned int argument is..."
>
> and, later, paragraph 9 says
>
> "... If any argument is not the correct type for the corresponding
> conversion specification, the behavior is undefined."
>
> So I am left wondering how one can know that int (the promoted type
> when no cast is used) is "the correct type" for the 'u' conversion
> specification.

I believe the rule about variadic arguments applying to printf
arguments is both what was intended and how the C standard is
generally read by others, including in particular implementors.
Consider two possibilities:

One: the rules for type correctness for printf arguments are
defined only by the somewhat vague phrase "the correct type" and
are different from the rules for other functions taking variadic
arguments; or

Two: the rules for type correctness for printf arguments are the
same as the rules for type correctness for other functions taking
variadic arguments (taking into account of course that different
specifiers imply different nominal argument types).

For completeness I should mention the reference Keith Thompson
pointed out, 7.16.1.1 (paragraph 2), that gives this rule for
the 'va_arg' macro, ie, that the corresponding unsigned type
is okay for a signed type specification, and vice versa, provided
the argument value given is representable in both types.

Are the rules for type correctness for printf idiosyncratic and
specific to printf, or are they the same as other variadic
functions? To me the second case seems much more likely.

Note that both gcc and clang, running with a -Wformat option
given, accept with no diagnostic a signed argument for an
unsigned specifier, and vice versa.

At this point I realized that I haven't really responded to your
implied question about "how one can know that", for example, an
int can be given for a %u conversion sequence. At least right
now I think the best answer I can give you is to think like an
implementor. The people who write the C standard aren't lawyers,
they are regular software developers, with a fair amount of
implementation experience. They aren't thinking mainly about the
words. They are, I belive, thinking first in terms of how things
are implemented, and only later about how to express that in
normal written language. If we think about it in terms of
implementation the relationship seems pretty straightforward.
The allowance for unsigned/signed interchangeability is given
explicitly in the description for va_arg; usually the C standard
avoids giving the same rule in more than one place, so it isn't
surprising that it wouldn't be repeated in the description of
arguments for *printf functions, but instead just referred to by
the phrase "the correct type". Does that make sense?

Incidentally, in C90 neither the sentence about "the correct type"
nor the extra type rules for va_arg were present. Both were added
in C99. I don't know whether that has any bearing on the question
at hand, but it's an interesting historical coincidence.

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.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> 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.

I mostly agree, but I disagree with your statement about the va_arg
rules applying to *printf.

The standard doesn't say that the *printf functions use va_arg. The
question of whether the standard *actually says* that va_arg rules apply
to *printf functions is, I think, answerable, and the answer is no.

Whether that matters is another question, but surely a question about
whether the standard says something can be resolved by reading the
standard.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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:
>>
>>> 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.
>
> I mostly agree, but I disagree with your statement about the va_arg
> rules applying to *printf.
>
> The standard doesn't say that the *printf functions use va_arg. The
> question of whether the standard *actually says* that va_arg rules
> apply to *printf functions is, I think, answerable, and the answer
> is no.
>
> Whether that matters is another question, but surely a question
> about whether the standard says something can be resolved by reading
> the standard.

I think you misunderstood what I was saying. There is no
question about what words are present. What the words mean is
another story. In many cases if not most cases the meaning
of sentences written in English is at least partly subjective.
That is the case here. To talk about what the words "actually
say" is to talk about meaning, and here the meaning is
ambiguous. The phrase "the correct type" is not well-defined.
In fact, since it has not been given an explicit definition,
someone might conclude that a *printf format that needs any
arguments at all will necessarily lead to undefined behavior.
I think you want to ascribe some sort of objective meaning
to the text, but the use of the undefined phrase "the correct
type" makes that impossible.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
>>> 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.
>>
>> I mostly agree, but I disagree with your statement about the va_arg
>> rules applying to *printf.
>>
>> The standard doesn't say that the *printf functions use va_arg. The
>> question of whether the standard *actually says* that va_arg rules
>> apply to *printf functions is, I think, answerable, and the answer
>> is no.
>>
>> Whether that matters is another question, but surely a question
>> about whether the standard says something can be resolved by reading
>> the standard.
>
> I think you misunderstood what I was saying. There is no
> question about what words are present. What the words mean is
> another story. In many cases if not most cases the meaning
> of sentences written in English is at least partly subjective.
> That is the case here. To talk about what the words "actually
> say" is to talk about meaning, and here the meaning is
> ambiguous. The phrase "the correct type" is not well-defined.
> In fact, since it has not been given an explicit definition,
> someone might conclude that a *printf format that needs any
> arguments at all will necessarily lead to undefined behavior.
> I think you want to ascribe some sort of objective meaning
> to the text, but the use of the undefined phrase "the correct
> type" makes that impossible.

I think it's not so much misunderstanding as disagreement.

You wrote:

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 simply disagree. It is an answerable question, and the answer is no;
the standard does not say that anywhere. It provides <stdarg.h> as *a*
mechanism for implementing variadic functions, and specifies the rules
that apply when va_arg is used, but it simply does not say that printf
is implemented using va_arg or that it follows the rules specified for
va_arg. A footnote says "The macros defined in the <stdarg.h> header
(7.16) may be used to access arguments that correspond to the
ellipsis.", which clearly implies the possibility of other mechanisms.

If it said that, there would be words to that effect. There
aren't. (Of course I'm open to correction if I'm missed something.)

As for "the correct type", I suggest that that phrase is inconsistent
with there being more than one correct type. The phrase "the correct
type" is not rigorously defined, but it is unambiguous that it refers to
one type. int and unsigned int are two distinct types; it is not
possible that they can both qualify as "the correct type". If it had
said "a correct type", that would leave open the possibility that either
int or unsigned int might be correct as an argument corresponding to
"%d", for example.

You see ambiguity in the words used in the standard that, as I read it,
just isn't there.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>>>> 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.
>>>
>>> I mostly agree, but I disagree with your statement about the va_arg
>>> rules applying to *printf.
>>>
>>> The standard doesn't say that the *printf functions use va_arg. The
>>> question of whether the standard *actually says* that va_arg rules
>>> apply to *printf functions is, I think, answerable, and the answer
>>> is no.
>>>
>>> Whether that matters is another question, but surely a question
>>> about whether the standard says something can be resolved by reading
>>> the standard.
>>
>> I think you misunderstood what I was saying. There is no
>> question about what words are present. What the words mean is
>> another story. In many cases if not most cases the meaning
>> of sentences written in English is at least partly subjective.
>> That is the case here. To talk about what the words "actually
>> say" is to talk about meaning, and here the meaning is
>> ambiguous. The phrase "the correct type" is not well-defined.
>> In fact, since it has not been given an explicit definition,
>> someone might conclude that a *printf format that needs any
>> arguments at all will necessarily lead to undefined behavior.
>> I think you want to ascribe some sort of objective meaning
>> to the text, but the use of the undefined phrase "the correct
>> type" makes that impossible.
>
> I think it's not so much misunderstanding as disagreement.
>
> You wrote:
>
> 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 simply disagree. It is an answerable question, [...]

The question I am considering does not have an objective answer.
Did you not understand that?

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> I think it's not so much misunderstanding as disagreement.
>>
>> You wrote:
>>
>> 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 simply disagree. It is an answerable question, [...]
>
> The question I am considering does not have an objective answer.
> Did you not understand that?

I understood what you said. I think you're wrong. Did you not
understand that?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */