> Well, or maybe not. The one problem there is new changes in GCC which assume that all sorts of things that used to work (and were thus de facto implementation-defined) are no longer happening in programs (because they are undefined behavior, so who would do that?) Thus even if the target hardware has stable two's complement behavior on a left shift that alters the sign of a value, and that has worked fine for years, an updated GCC can suddenly decide that it's okay optimize based on the idea that the program doesn't do such a thing.

Note that Linux compiles with -fwrapv or one of the similar flags that defines overflow to wrap, so this isn’t an issue. I guess this trivializes this patch more, but I figured that they might want the patch anyways in case they ever move off of the flag. (I couldn’t find a uloff_t, so I copied what other code seemed to be doing in this case.)