@Campbell Barton (campbellbarton), I tried to ask your about adding you to review this diff, but we kept missing each other. I hope this isn't any inconvenience.

Doesn't modifying the input memory mean loading an icon twice will not work properly the second time?

As this isn't a user facing bug, I'd rather not have an over complicated solution.

In this case I think it's worth checking on treating colors as uint8_t[4] instead of a uint32_t, a struct containing RGBA can be used to make it clearer whats intended.

When discussing with @Campbell Barton (campbellbarton), he pointed out that the file buffer may be memorized and should therefore be treated as immutable. The coords and colors buffers are allocated in either of two ways. Either as two distinct buffers, or as two regions after the icon structure… therefore they are deallocated differently in these two cases. The best solution may be to duplicate the buffer on misalignment, I need to trace buffer ownership to do this properly, especially if memorized. A different option could be allocate a temporary buffer on rasterization. This is probably less efficient.

Note that BKE_icon_geom_invert_lightness does manipulate the data passed into the icon creation function although I wouldn't mind changing this so the memory is considered immutable. It's also not high priority.

In D15262#412104, @Campbell Barton (campbellbarton) wrote:

… a struct containing RGBA can be used to make it clearer whats intended.

Actually, an RGBA struct sounds so much less confusing, I’m tempted to go with that. (The fact that we walk through the col array by steps of 3, even though that was 3 32-bit ints/12 bytes, I took as a false flag, I seriously questioned if the data was striped as RRRRGGGGBBBB for some reason.) BTW, why *are* we walking through the data 3 pixels at a time?