Re: "undefined behavior"?

On 16/06/2024 11:53, David Brown wrote:

On 15/06/2024 21:27, Richard Harnden wrote:

On 15/06/2024 19:57, David Brown wrote:

>
If you want BBX_RGBA to be a typedef for an unsigned 32-bit integer, write:
>
     typedef uint32_t BBX_RGBA;
>
If you want bbx_rgba() to be a function that is typesafe, correct, and efficient (for any decent compiler), write :
>
     static inline BBX_RGBA bbx_rgba(uint32_t r, uint32_t g,
             uint32_t b, uint32_t a)
     {
         return (r << 24) | (g << 16) | (b << 8) | a;
     }
>

>
Shouldn't that be ... ?
>
static inline BBX_RGBA bbx_rgba(uint8_t r, uint8_t g,
         uint8_t b, uint8_t a)
>

 As Ben says, that will not work on its own - "r" would get promoted to signed int before the shift, and we are back to undefined behaviour.
 I think there is plenty of scope for improvement in a variety of ways, depending on what the author is looking for.  For example, uint8_t might not exist on all platforms (indeed there are current processors that don't support it, not just dinosaur devices).  But any system that supports a general-purpose gui, such as Windows or *nix systems, will have these types and will also have a 32-bit int.  So the code author can balance portability with convenient assumptions.
 There are also balances to be found between run-time checking and efficiency, and how to handle bad data.  If the function can assume that no one calls it with values outside 0..255, or that it doesn't matter what happens if such values are used, then you don't need any checks. As it stands, with uint32_t parameters, out-of-range values will lead to fully defined but wrong results.  Switching to "uint8_t" types would give a different fully defined but wrong result.  Maybe the function should use saturation, or run-time checks and error messages - that will depend on where it is in the API, what the code author wants, and what users expect.
 

It's the general function which converts reba quads or rgb triplets (with a little wrapper) to opaque colour values to pass about to graphics functions. And currently it's not used to access the raster for BBX_Canvas elements.
But that's where Baby X does a lot of work which is a target for optimisation. And the opaque format might have to change to match the internal format used by the platform. However optimising the graphics isn't the priority for now, which is getting the API and the documentation right.
And what should happen if user passes wrong values? Since the function is provided as a macro rather than a subroutine, it's kind of accepted that it is too low-level for error checking. So user will usually draw the wrong colour on his screen, which might be a hard bug to diagnose.
But yes, this is absolutely the sort of thing you need to get right.
--
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc