Re: "undefined behavior"?

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.

Yes, the fact that incorrect printf format strings cause undefined
behavior, and that that's sometimes difficult to diagnose, is a
language problem.  I don't recall anyone saying it isn't.  But it's
really not that hard to deal with it as a programmer.

It is particularly easy if you have a decent compiler and know how to enable the right warning flags!

 If you have ideas (other than abandoning C) for a flexible
type-safe printing function, by all means share them.  What are your
suggestions?  Adding `print` as a new keyword so you can use `print
foo` is unlikely to be considered practical; I'd want a much more
general mechanism that's not limited to stdio files.  Reasonable new
language features that enable type-safe printf-like functions could
be interesting.  I'm not aware of any such proposals for C.
 

It is possible to come a long way with variadic macros and _Generic. You can at least end up being able to write something like :
int x = 123;
const char * s = "Hello, world!";
uint64_t u = 0x4242;
Print("X = ", x, " the string is ", s, " and u = 0x",
as_hex(u, 6), newline);
rather than:
printf("X = %i the string is %s and u = 0x%06lx\n");
Which you think is better is a matter of opinion.

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.