On Fri, Feb 26, 2010 at 8:12 AM, Vincent Torri <vto...@univ-evry.fr> wrote: > On Fri, 26 Feb 2010, Gustavo Sverzut Barbieri wrote: > >> On Fri, Feb 26, 2010 at 4:22 AM, Vincent Torri <vto...@univ-evry.fr> >> wrote: >>> >>> On Thu, 25 Feb 2010, Enlightenment SVN wrote: >>>> >>>> Log: >>>> TRUE/FALSE are gone, use EINA_TRUE/EINA_FALSE instead. >>>> >>>> Author: barbieri >>>> Date: 2010-02-25 16:59:11 -0800 (Thu, 25 Feb 2010) >>>> New Revision: 46500 >>>> >>>> Modified: >>>> trunk/eina/src/include/eina_types.h >>>> >>>> Modified: trunk/eina/src/include/eina_types.h >>>> =================================================================== >>>> --- trunk/eina/src/include/eina_types.h 2010-02-26 00:57:20 UTC >>>> (rev 46499) >>>> +++ trunk/eina/src/include/eina_types.h 2010-02-26 00:59:11 UTC >>>> (rev 46500) >>>> @@ -214,25 +214,13 @@ >>>> #endif /* ! __GNUC__ && ! _WIN32 && ! __SUNPRO_C */ >>>> >>>> >>>> -/* remove this TRUE/FALSE redifinitions */ >>>> - >>>> /** >>>> - * @deprecated Use #EINA_TRUE instead. >>>> - */ >>>> -#ifndef TRUE >>>> -# define TRUE 1 >>>> -#endif >>>> - >>>> -/** >>>> - * @deprecated Use #EINA_FALSE instead. >>>> - */ >>>> -#ifndef FALSE >>>> -# define FALSE 0 >>>> -#endif >>>> - >>>> -/** >>>> * @typedef Eina_Bool >>>> * Type to mimic a boolean. >>>> + * >>>> + * @note it differs from stdbool.h as this is defined as an unsigned >>>> + * char to make it usable by bitfields (Eina_Bool name:1) and >>>> + * also take as few bytes as possible. >>>> */ >>>> typedef unsigned char Eina_Bool; >>> >>> char bitfields are an extension of gcc (and of some other compilers). >>> The C standard says that "fields are packed into 'storage units', which >>> are typically machine words". Compile a small example with gcc -pedantic >>> and you'll see a warning. C99 allows _Bool, though. >>> >>> I'm not sure at all that they will take as few bytes as possible in the >>> sense that you implicitely say (one char -> only 1 byte in memory). They >>> are always aligned to 32 bits. They just need to be consecutive to take >>> the less space in memory as possible. If you use some gcc options to pack >>> bitfields, be aware that the library might not be working at all with >>> vc++ >>> as the way vc++ pack bitfields is different. That said, you'll certainly >>> add that Windows is my territory, not yours :p >> >> damn, if it breaks then we need to convert from char to int ASAP, so >> we don't break the ABI after release. >> >> I'm quite sure this is in lots, lots of code paths in EFL/E17 now, so >> it should "just work", no? > > I've found that option to gcc (mingw): > > -mms-bitfield > > it should solve the problem when compiling the efl on Windows. > > anyway, i think that your note is not entirely correct
but should we keep using it as uchar or move to uint? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
