Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#939 closed bug (fixed (in master))

Should color*255 be color*257?

Reported by: h.b.furuseth@… Owned by:
Milestone: 3.1.2 beta Keywords: display x11 blocker
Cc:

Description

main-x11.c:create_pixel() multiplies 1-byte color values with 255:

xcolour.red = red * 255;
xcolour.green = green * 255;
xcolour.blue = blue * 255;

If it's meant to map the input values to the whole spectrum of
XColor values, it should multiply with (65535U / 255) = 257U.
(BTW, note the `U' - it's needed on 16-bit hosts.)

[Copied from a rgra posting from 2001, where I confused black
with white]

Change History (4)

comment:1 Changed 10 years ago by takkaria

  • Milestone changed from Triage to 3.1.2 beta
  • Status changed from new to confirmed

comment:2 Changed 10 years ago by takkaria

  • Keywords blocker added

comment:3 Changed 10 years ago by d_m

  • Resolution set to fixed
  • Status changed from confirmed to closed

I applied this change and it seems to work fine. I'm not sure I totally get why it's necessary (I've not programmed with Xlib much) but since it was believed to be an issue and seems to work I've committed it in [a60bf67] (SVN r1896).

comment:4 Changed 10 years ago by h.b.furuseth@…

I too don't know Xlib. I just saw some code I guessed intended to do
something else than it was doing, so I reported it. Specifically, it
mapped the 8-bit color range 00-FF to the 16-bit color range 0000-FE01
(255*255) instead of to the whole 16-bit range 0000-FFFF.

BTW, using 257 instead of 257U, your update can still overflow on
hosts with 16-bit int, if anyone cares about these. Probably a
lot of other code has the same problem though.

Regards,
Hallvard

Note: See TracTickets for help on using tickets.