[Rpm-maint] [rpm-software-management/rpm] Avoid undefined shifts (#1547)

[Panu Matilainen]

Yeah, I've ran into this as well, on more than one occasion. Rant alert... :warning: 

Here's what C99 standard says of it:

> The  result  of E1 << E2 is E1 left-shifted E2 bit  positions;  vacated  bits  are  filled  with zeros.  If E1 has  an  unsigned  type,  the  value  of  the  result  is E1×2^E2, reduced  modulo one  more  than  the  maximum  value  representable  in  the  result  type.If E1 has  a  signed type  and  nonnegative  value,  and E1×2^E2 is  representable  in  the  result  type,  then  that  is the resulting value; otherwise, the behavior is undefined.

...and...

> Each  enumerated  type  shall  be  compatible  with char, a signed  integer  type,  or  an unsigned  integer  type. The  choice  of  type  is  implementation-defined, but shall  be capable   of   representing   the   values   of   all   the   members   of   the   enumeration. The enumerated  type  is  incomplete  until  after  the that  terminates  the  list  of  enumerator declarations.

To me that reads the compiler is responsible for figuring out the proper type for the enum, and meanwhile *we* don't actually care whether it thinks its signed or not because it's just an effing bitfield. However I'm quite positive any old number of compiler authors will disagree with my assessment. I deeply hate this language-lawyering - this is C, your friendly high-level assembler, and a bit-shift is a bit-shift regardless of the compiler vintage, damnit :unamused: 

I remember trying this very thing at some point, only to find that our Python (2.x) bindings blew up on 32bit systems because it couldn't represent the *unsigned* values. That's not an issue in Python 3 anymore, just noting that these kind of changes are not without risk.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1547#issuecomment-799401476
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20210315/5c0bef70/attachment.html>