On Thu, Oct 08, 2026 at 11:31:10AM -0600, Ted Bullock wrote:
> Also, b and f are signed int values, so the cast can corrupt the
> adjacent pixel. For example, white after byte swapping is 0xc7c7c700:
> 
>     (uint64_t)f            /* 0xffffffffc7c7c700 */
>     (uint64_t)(uint32_t)f  /* 0x00000000c7c7c700 */

Yes, this is true, the sign extension of any byte swapped values that become
negative will indeed corrupt the neighbouring value.

But just casting the device colourmap entries to uint32_t here also seems like
yet another cludge, because these values should never need to be interpreted
as signed in the first place.  Rasops does bitwise operations all over the
place, and bit operations on negative signed values are not strictly defined.

The raw ANSI colourmap entries from which the device colourmap is derived are
unsigned.

I know that the method you suggest of swapping the assignments to u.d[1] and
u.d[2] is simple and produces the required result, but it's still relying on
unspecified behaviour.  That just happens to work in this case but could
easily break in others.

Whilst we're here, we might as well try to fix it once and for all in a
standards defined way that can be expected to work on any endian combination.