[opensource-dev] Problems porting VWR-12984 to snowglobe 2.0

[lists.secondlife.com at trap.wereanimal.net]

When porting over VWR-12984, I hit a snag. Turns out an enum was added to from 
1.x to 2.x that put it at 32 bits. The port added one more causing to go over 
to 33 bits. From the comments section of the jira.

======
These warnings are indeed sign of a serious problem: The enum's values are 
used to shift a 1 (a set bit) around within (32-bit) ints, to produce flags 
and masks. Other than in Snowglobe 1.x, the enum already had 32 values before 
the patch. The patch added a 33rd, pushing the shifted-around 1 off the type 
size boundary.

This results in some objects staying blurry and and others disappearing 
seemingly at random or not showing at all. Most of the values of the enum are 
being assigned values from other enums, so either this was very, very 
carefully crafted or we were extremely "lucky" that the bit-shifting didn't 
push the 32bit limit already before this patch.

The warnings can be avoided by doing the shifting within long ints instead of 
ints. This of course doesn't solve the problem, as the types of the variables 
to which the resulting masks get assigned are still too small and would have 
to be changed, too. (Which could lead to other variables and constants having 
to be changed. Didn't check that, yet.)

If (at least) one of the values of the enum isn't used to shift bits around (I 
haven't looked yet whether that's the case), that one could be put at the end 
of the enum, thus keeping the others below 32. However, that solution would be 
even hackier than than the current code and would cause major maintenance 
headaches. (E.g., what happens when that value has later to be used to define 
a mask, too?)
========

My question for the group is how is the best way to fix this? Can 
RENDER_TYPE_PASS_* be moved into its own enum?

--Techwolf Lupindo