Re: "undefined behavior"?

David Brown <david.brown@hesbynett.no> writes:

On 14/06/2024 00:58, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 13/06/2024 16:39, Scott Lurndal wrote:

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

On 13/06/2024 01:33, Keith Thompson wrote:

If foo is an int, for example, printf lets you decide how to print
it (leading zeros or spaces, decimal vs. hex vs. octal (or binary
in C23), upper vs. lower case for hex).  Perhaps "print foo" in
your language has similar features.

>
C23 also adds explicit width length modifiers.  So instead of having
to guess if uint64_t is "%llu" or "%lu" on a particular platform, or
using the PRIu64 macro, you can now use "%w64u" for uint64_t (or
uint_least64_t if the exact width type does not exist).  I think
that's about as neat as you could get, within the framework of printf.

Note that the new "%wN" modifier applies only to [u]intN_t and
[u]int_leastN_t types, not to all integer types with a width of N bits.

The standard doesn't guarantee that integer types with the same
representation are interchangeable, so for example printf("%d", 0L) and
printf("%ld", 0) both have undefined behavior.  An implementation would
probably have to go out of its way to make either of those do anything
other than printing "0", but the behavior is still undefined (i.e., the
standard doesn't guarantee it will work).

That's still the case in C23, even for the %wN modifiers.  For a typical
implementation with 32-bit integer types, uint32_t and uint_least32_t
will be the same type (C17 doesn't require that), and "%w32u" will work
with that type.  It's not guaranteed to work with any other 32-bit
unsigned type.  For an implementation that doesn't have any 32-bit
integer type, uint32_t won't exist, uint_least32_t will be, say, 64
bits, and "%w32u" will work with *that* type.

That covers the exact-width and "least" types.  The "%wfN" modifiers
cover the "fast" types.

So if you want to use C23's new "%wN" modifiers, you have to use the
types defined in <stdint.h> if you want to avoid undefined behavior.
On the other hand, though `int n = 42; printf("%w32d\n", n);` has
undefined behavior, it's very very likely to work if int is 32 bits.
(`gcc -Wformat` warns about using "%ld" with a long long argument
even when long and long long have the same size, but not about using
"%w32d" with a 32-bit int argument.)

The new modifiers are supported in glibc 2.39, which is included in
Ubuntu 24.04.  They're not supported in newlib (used by Cygwin) or in
MS Visual Studio 2022.

[...]

I wouldn't mind seeing a new kind of typedef that creates a new type
rather than an alias.  Then uint64_t could be a distinct type.
That could cause some problems for _Generic, for example.

>
I too would like such a typedef.  Using it for uint64_t would cause
problems for /existing/ uses of _Generic, but would make future uses
better.

Currently, there are (in the absence of extended integer types) only a
finite number of incompatible integer types.  This makes it possible to
write a _Generic expression that accepts an operand of any integer type,
which can be useful if you have an integer typedef and don't know the
underlying type.  This new kind of typedef would allow programmers to
introduce an unlimited number of new incompatible integer types.

I haven't seen a lot of code that does that kind of thing, and none
that I didn't write myself.

Perhaps if this is introduced, there should be a way to determine the
underlying type.  C23 introduces typeof and typeof_unqual; perhaps we
could have typeof_underlying.  It could also apply to enum types.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */