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 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> <87o784xusf.fsf@bsb.me.uk> <87ikybycj6.fsf@bsb.me.uk> <87cyojxlgj.fsf@bsb.me.uk> 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 writes: > On 14/06/2024 22:29, Ben Bacarisse wrote: >> Malcolm McLean writes: >> >>> On 14/06/2024 12:44, Ben Bacarisse wrote: >>>> Malcolm McLean writes: >>>> >>>>> On 14/06/2024 00:55, Ben Bacarisse wrote: >>>>>> Malcolm McLean 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.