Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Kamil Dudka <[EMAIL PROTECTED]> writes:
>> On Wednesday 03 September 2008 11:03:22 you wrote:
>>> Kamil Dudka <[EMAIL PROTECTED]> writes:
>>> Since both arguments are already bool I see no need for LOG_EQ (it's the
>>> only use anyway).
>> If you are using type bool, there is no guarantee there will be bool (0/1)
>> value inside.
>
> RTFS. It _is_ guaranteed. Even if bool != C99 _Bool.
In general, when using gnulib's replacement via stdbool.in.h,
the following comment from that file is relevant:
/* Usage suggestions:
Programs that use <stdbool.h> should be aware of some limitations
and standards compliance issues.
Standards compliance:
- <stdbool.h> must be #included before 'bool', 'false', 'true'
can be used.
- You cannot assume that sizeof (bool) == 1.
- Programs should not undefine the macros bool, true, and false,
as C99 lists that as an "obsolescent feature".
Limitations of this substitute, when used in a C89 environment:
- <stdbool.h> must be #included before the '_Bool' type can be used.
- You cannot assume that _Bool is a typedef; it might be a macro.
- Bit-fields of type 'bool' are not supported. Portable code
should use 'unsigned int foo : 1;' rather than 'bool foo : 1;'.
>> - In C99, casts and automatic conversions to '_Bool' or 'bool' are
>> performed in such a way that every nonzero value gets converted
>> to 'true', and zero gets converted to 'false'. This doesn't work
>> with this substitute. With this substitute, only the values 0 and 1
>> give the expected result when converted to _Bool' or 'bool'.
Also, it is suggested that programs use 'bool' rather than '_Bool';
this isn't required, but 'bool' is more common. */
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
