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
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
