Re: "undefined behavior"?

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