Re: "undefined behavior"?

On 13/06/2024 20:34, Chris M. Thomasson wrote:

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?
 

Not really. For instance the shell gives the user the option to specify an editor with the -editor option, The program then duplicates that string.
Now in any legitimate scenario, that string will be few hundred characters at the most, and be some complex path on a weird and wonderful filing system. And normally the editor will be within the host shell's execution evironment, and the string will be "vi" or "emacs" or similar. And the program is not going to allocation fail at that point, and if it does, yes someone has defeated the usual restriction on OS line length and is playing silly games, so it is best to pack up and go home.
--
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc