Re: "undefined behavior"?

On 6/13/2024 11:54 AM, Malcolm McLean wrote:

On 13/06/2024 19:01, bart wrote:

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.

 >
Exactly. We can't have this just to print out an integer.
 In Baby X I provide a function called bbx_malloc(). It's is guaranteed never to return null. Currently it just calls exit() on allocation failure.

[...]
It calls exit() on an allocation failure? Is that rather harsh, humm...? Let the program decide on what to do?