Re: "undefined behavior"?

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.

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

Imgage buffer are arrays of unsigned char holding 32 bit rgba values in the order red, green, blue, alpha, always and regardless of the format used on the host platform.
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;
#define bbx_rgba(r,g,b,a) ((BBX_RGBA) ( ((r) << 24) | ((g) << 16) | ((b) << 8) | (a) ))
#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)
#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.
Now of course C will allow you to create images using arrays of BBX_RGBAs, but Baby X programmers must not do that, or their programs may break if endianess switches or long has more than 32 bits, and the point of Baby X that it never breaks, it always runs everywhere and anywhere there is a C compiler and a windowing library we can retarget bbxlib at.

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

Images do hold rgba values, of course. But no, I'm not defining a new image format for Baby X. A Filesystem XML format, yes, a new image format, no.
--
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc