Hi Elnatan!
> CIL mistakenly casts the operands of && and || to intType, when in
> fact they are only required to have scalar type. This can lead to a
> bug if the operands have type larger than int and have values which
> truncate to 0 when cast to an int (and if useLogicalOperators is set
> to true).
IIRC, the C Standard says both operands of the logical
operators _separately_ undergo the "usual unary conversions".
Sloppily phrased, this means all integers with a conversion
rank (CR) less than 40 get promoted to those with CR 40,
i.e. "int" or "unsigned int", and any with a higher CR are left
untouched.
> I believe removing the cast solves the problem, but I'm not
> sure whether enumerations should still be cast to intType.
The Standard only requires that enumerations are
represented as an implementation-defined integer type. I know
compilers that use "char", "short int", or "int" depending on the
number of elements in a particular enum. However, it is
conceivable that a compiler wants to encode a huge enum (think of
auto-generated parser jump tables) as "long int", i.e. at CR 50.
In this case a cast-to-int could be fatal.
If we can rely on the ekind field of enuminfo, we could trivially
cast the enum to its ekind and then perform the "usual unary
conversions". What do you think about that?
Cheers,
Chris
--
Dr. Christoph L. Spiel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
CIL-users mailing list
CIL-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cil-users
