On Tue, May 20, 2008 at 6:46 PM, Kim Woelders <[EMAIL PROTECTED]> wrote: > Gustavo Sverzut Barbieri wrote: >> >> to make clear: it COULD be -0, on intel at least it's -1 and thus >> evaluates to TRUE, that's why it was unnoticed. >> >> On Tue, May 20, 2008 at 5:56 PM, Enlightenment CVS >> <[EMAIL PROTECTED]> wrote: >>> >>> Enlightenment CVS committal >>> >>> Author : barbieri >>> Project : e17 >>> Module : libs/evas >>> >>> Dir : e17/libs/evas/src/lib/include >>> >>> >>> Modified Files: >>> evas_common.h >>> >>> >>> Log Message: >>> Remove bugs with bitfield usage, make boolean usage clear. >>> >>> This patch fixes the problem with bitfield of signed types (ie: char), >>> where the bit would be used for the signal, so 1 is considered -0 and >>> thus 0. >>> >>> Move all the single bit fields to Evas_Bool, making it clear and also >>> avoiding these problems since Evas_Bool is unsigned char. >>> > Compilers may complain about signed one bit bitfields, but it is severely > broken if a signed one bit bitfield set to 1 evaluates to 0.
i see this fact somewhere. > I would have thought that a signed one bit bitfield set to 1 normally > evaluates to -1 which is != TRUE, assuming TRUE is 1. exactly, forgot to say that. > Furthermore, you should not assume anything about the signedness of char. It > depends on compiler configuration. exactly, that's why it's now forced to unsigned. on arm it's unsigned, but on pc it's not. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
