Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: "undefined behavior"?
Date: Thu, 13 Jun 2024 12:34:45 -0700
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <v4fhkm$2dbap$5@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 13 Jun 2024 21:34:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="657fcb6577726c32320ac74d3761bcf6";
	logging-data="2534745"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19pVT16x1JaSe5aTdtUksg8B2PQEZKCnoU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:O7uEaViTzoxGn8Q2YSULekJ43yA=
In-Reply-To: <v4ff97$2d8l1$1@dont-email.me>
Content-Language: en-US
Bytes: 3969

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?