Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: "undefined behavior"?
Date: Fri, 14 Jun 2024 12:44:13 +0100
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <87ikybycj6.fsf@bsb.me.uk>
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> <v4g7i3$2icc2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Jun 2024 13:44:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="857528a8b109889a6f438cbb5df2d776";
	logging-data="3023274"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Rm9ukaIyaDsohUDA4d0LBSvkS2LRs/LY="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:+RjuscSShKVSTNXW3X4NnLPjO0Y=
	sha1:oiKKAvu4z/eR7r24Y6Bu7mJNt6Q=
X-BSB-Auth: 1.9de90976d2865f56604c.20240614124413BST.87ikybycj6.fsf@bsb.me.uk
Bytes: 3962

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> 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.

Neither is malloc but you wanted t replace that to get rid of the need
for size_t.

I confess that I am all at sea about what you are doing.  In essence, I
don't understand the rules of the game so I should probably just stop
commenting.

>>> 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.

Right.  So you don't always use long for "holding rgba values".  Another
rule I didn't know.

> 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,

Which is why I thought you might be including images in the notion of
"holding rgba values".

-- 
Ben.