Re: [protobuf] zigzag encode and zigzag decode invoking undefined behavior

If you have a change that makes protobuf code not rely on undefined behavior, and also doesn't sacrifice performance, then we should merge it. Feel free to send a GitHub PR. But make sure the code is C++03 (protobuf doesn't use C++11 yet). On Tuesday, April 25, 2017 at 1:36:31 PM UTC-7,

Re: [protobuf] zigzag encode and zigzag decode invoking undefined behavior

I know, but the proposed solution is still worth considering as it gives you the best of both worlds with just a little compile time overhead. It yields the same result on 2s complement machines as the current function but also on other machines because it is well defined. This means that

Re: [protobuf] zigzag encode and zigzag decode invoking undefined behavior

Right now protobuf implementation assumes 2s complement and won't work on any other environments. That's undefined behavior according to C++ standard but in practice it's very unlikely to be a problem. On Tue, Apr 25, 2017 at 5:42 AM, Wolfgang Brehm wrote: > right

[protobuf] zigzag encode and zigzag decode invoking undefined behavior

right shifting negative integers is tecnically undefined, this means that the implementation used for encoding integers: (n<<1)^(n>>(digits-1)) is tecnically undefined according to: > The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits > are zero-filled. If E1 has an