Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)

[Jim Meyering]

Andreas Schwab <address@hidden> wrote:
> Kamil Dudka <address@hidden> writes:
>> On Wednesday 03 September 2008 11:03:22 you wrote:
>>> Kamil Dudka <address@hidden> 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.  */