Re: "undefined behavior"?

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:

>
printf is a variadic function, so the types of the arguments after
the format string are not specified in its declaration.  The printf
function has to *assume* that arguments have the types specified
by the format string.  This:
      printf("%d\n", foo);
(probably) has undefined behavior if foo is of type size_t.
>

And isn't that a nightmare?

 No, because compilers have been able to diagnose mismatches
for more than two decades.

What about the previous 3 decades?
What about the compilers that can't do that?
What about even the latest gcc 14.1 that won't diagnose it even with -Wpedantic -Wextra?
What about when the format string is a variable?
What about the example given below?
It is definitely a language problem. Dealing with some of it with some compilers with some options isn't a solution, it's just a workaround.
Meanwhile for over 4 decades I've been able to just write 'print foo' with no format mismatch, because such a silly concept doesn't exist. THAT's how you deal with it.

 

>
We just can't have size_t variables swilling around in prgrams for these
reasons.

 POSIX defines a set of strings that can be used by a programmer to
specify the format string for size_t on any given implementation.

And here it just gets even uglier. You also get situations like this:
     uint64_t i=0;
     printf("%lld\n", i);
This compiles OK with gcc -Wall, on Windows64. But compile under Linux64 and it complains the format should be %ld. Change it to %ld, and it complains under Windows.
It can't tell you that you should be using one of those ludicrous macros.
I've also just noticed that 'i' is unsigned but the format calls for signed. That may or may not be deliberate, but the compiler didn't say anything.