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: Sat, 15 Jun 2024 00:14:22 +0100
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <871q4zxgkx.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>
	<87ikybycj6.fsf@bsb.me.uk> <v4hk5v$2tttf$1@dont-email.me>
	<87cyojxlgj.fsf@bsb.me.uk> <v4igj8$330vf$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 15 Jun 2024 01:14:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="380eada212a615501ba8464307a3ba59";
	logging-data="3258708"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+p9c+xaxgcxOkWoRL/5tQ9dY/OTc84z3Q="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:tjjjuf03NheednrS+cOVswhqBB4=
	sha1:pmz1/9fk8yiqriy3Cs006TQnUtw=
X-BSB-Auth: 1.e0cee19f4eabb4399b52.20240615001422BST.871q4zxgkx.fsf@bsb.me.uk
Bytes: 6640

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

> On 14/06/2024 22:29, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> 
>>> On 14/06/2024 12:44, Ben Bacarisse wrote:
>>>> 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.
>>>>
>>> Yes, I really need to get that website together so that people cotton on to
>>> what Baby X is, what it can and cannot do, and what is the point.
>> I know what Baby X is.  I don't know why "these are not Baby X
>> functions" applies to the ones I listed and not to malloc.
>> ...
>>> However if you need to pass a colour value to a fuction, you normall pass a
>>> BBX_RGBA value, which is typedefed to unsigned long, and is opaque, and you
>>> query the channels using the macros in bbx_color.h
>>>
>>> #ifndef bbx_color_h
>>> #define bbx_color_h
>>>
>>> typedef unsigned long BBX_RGBA;
>>
>> Curious.  The macros below seem to assume that int is 32 bits, so why
>> use long?

Why use long?

>>> #define bbx_rgba(r,g,b,a) ((BBX_RGBA) ( ((r) << 24) | ((g) << 16) | ((b) <<
>>> 8) | (a) ))
>> This is likely to involve undefined behaviour when r >= 128.  (I presume
>> you are ruling out int narrower than 32 bits or there are other problems
>> as well.)
>
> No, it's been miswritten. Which is what I mean about C's integer types
> being a source of bugs. That code does not look buggy, but it is.

I have no idea what this means.  You start with "no" but I can't work
out what you think is wrong about what I said.  And what does "has been
miswritten" mean?  Both the tense and the use of "miswritten" are
confusing to me.  And, to me, the code does look "buggy".

>>> #define bbx_rgb(r, g, b) bbx_rgba(r,g,b, 255)
>>> #define bbx_red(col) ((col >> 24) & 0xFF)
>>> #define bbx_green(col) ((col >> 16) & 0xFF)
>>> #define bbx_blue(col) ((col >> 8) & 0xFF)
>>> #define bbx_alpha(col) (col & 0xFF)
>> It might not be an issue (as col is opaque and unlikely to be an
>> expression) but I'd still write (col) here to stop the reader having to
>> check or reason that out.
>> 
>>> #define BBX_RgbaToX(col) ( (col >> 8) & 0xFFFFFF )
>>>
>>> #endif
>>>
>>> The last macro is to make it easier to interface with Xlib, and has the
>>> prefix BBX_ (upper case) indicating that it is for internal use by the bbx
>>> library / system and not meant for user programs.
>>
>> As a reader of the code, I made exactly the reverse assumption.  When I
>> see lower-case macros I assume they are for internal use.
>
> They're function-like macros. Iterating over an rgba buffer is very
> processor-intensive, and so we do haave to compromise sfatety for speed
> here.

I am not suggesting otherwise.

> All function-like symbols bbx_ are provided by Baby X for users, all
> symbols BBX_ have that prefix to reduce the chance of collisions with other
> code.

Clearly.  I'm not sure why you have reiterated this.  I did not intend
to change your mind, just to point out that it's the reverse of the
common convention.

-- 
Ben.