Path: ...!2.eu.feeder.erje.net!feeder.erje.net!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 02:48:51 +0100
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <v4g7i3$2icc2$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> <87o784xusf.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Jun 2024 03:48:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="35df34e3574a73517d6a229abcda4a8f";
	logging-data="2699650"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+tX0zKb0cS+SSvTnRqM/VyhroTPF6A9xs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:oCN4o8XhRKoDZ9HZWm9zJwnfxXM=
In-Reply-To: <87o784xusf.fsf@bsb.me.uk>
Content-Language: en-GB
Bytes: 4672

On 14/06/2024 00:55, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> 
>> On 13/06/2024 19:01, bart wrote:
> 
>>> 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.
> 
> This is how C works.  There's no point in moaning about it.  Use another
> language or do what you have to in C.
> 
>> 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.
>> But it also limits allocation to slightly under INT_MAX. Which should be
>> plenty for a Baby program, and if you want more, you always have big boy's
>> malloc.
> 
> And if you need to change the size?
> 
>> But at a stroke, that gets rid of any need for size_t,
> 
> But sizeof, strlen (and friends like the mbs... and wcs... functions),
> strspn (and friend), strftime, fread, fwrite. etc. etc. all return
> size_t.
> 
But these are not Baby X functions. Obviously Baby X isn't responsible 
if you call functions without the bbx_ prefix and things go wrong. But 
if you don' use standard library functions, thre should be no way in 
Baby X of creating an obect too big to be indexed as an array of 
unsigned char by an int. And so we simply do away with all the 
complexities of different integer types which make C code bug prone, 
hatd to read, and are of no real interest. The types are char, unsigned 
char, int, and double, depending on whether a value is aa ASCII 
cgaracter, a series of undefined bits, an integer, or a real value. And 
what could be more simple and sensible?

> For people taught to ignore size_t, care is also needed when calling
> functions that take size_t arguments as the signed to unsigned
> conversion can cause surprises when not flagged by the compiler.  I
> don't know if I am right, but I would bet that many of the "don't bother
> with size_t" crowd are also in the "don't bother with all those warning
> flags to the compiler" crowd.
> 
>> and long is very
>> special purpose (it holds the 32 bit rgba values).
> 
> Isn't that rather wasteful when long is 64 bits?
> 
No, because we store images as unsigned char buffers. But it's 
convenient to pass around coulor values in a single variable.
However there is the worry that accessing rgba channels as bytes rather 
than insisting that the buffer be aligned, and accessing as a 32-bit 
value, and pulling channels out with shifts and masking, might be a bit 
slower. C does provide a way to solve this, but only polluting the 
codebase, abd the current way is absolutely robust.

-- 
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc