Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> 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:
>
> It's not relevant here. The source already depends on the current
> guarantee for pure bool values.
It looks relevant to me, since we're using gnulib's stdbool and I think
we still care about portability to systems where the nonconforming
replacement is used.
I presume you're referring to uses of "bool" variables
like these (there are many more):
if (me_remote & show_local_fs)
return;
if (me_dummy & !show_all_fs & !show_listed_fs)
return;
Those uses of "&" should be changed to "&&",
so that the code will work even with our stdbool emulation.
Thanks for pointing that out.
On the other hand, this may be an indication that no one is using df
on a system for which that less-functional "bool" emulation is required.
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
