Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Malcolm McLean <malcolm.arthur.mclean@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: "undefined behavior"?
Date: Fri, 14 Jun 2024 00:32:55 +0100
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <v4fvj7$2gfm9$1@dont-email.me>
References: <666a095a$0$952$882e4bbb@reader.netnews.com>
 <8t3k6j5ikf5mvimvksv2t91gbt11ljdfgb@4ax.com>
 <666a18de$0$958$882e4bbb@reader.netnews.com>
 <87y1796bfn.fsf@nosuchdomain.example.com>
 <666a2a30$0$952$882e4bbb@reader.netnews.com>
 <87tthx65qu.fsf@nosuchdomain.example.com> <v4dtlt$23m6i$1@dont-email.me>
 <NoEaO.2646$J8n7.2264@fx12.iad> <v4fc5j$2cksu$1@dont-email.me>
 <v4ff97$2d8l1$1@dont-email.me> <v4fhkm$2dbap$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Jun 2024 01:32:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="35df34e3574a73517d6a229abcda4a8f";
	logging-data="2637513"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/8ATeCDdGRl9K73SzqqmhdPZXEgrg9Dfc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6fkpRE77iENC9BMcribQDFLgsSs=
Content-Language: en-GB
In-Reply-To: <v4fhkm$2dbap$5@dont-email.me>
Bytes: 4874

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