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 _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
