Nathan Scott wrote:
>On Mon, Sep 04, 2006 at 12:24:41PM +0200, Richard Knutsson wrote:
>
>
>>Nathan Scott wrote:
>>
>>
>>>Hmm, so your bool is better than the next guys bool[ean[_t]]? :)
>>>
>>>
>>Well yes, because it is not "mine". ;)
>>It is, after all, just a typedef of the C99 _Bool-type.
>>
>>
>
>Hmm, one is really no better than the other IMO.
>
>
IMO the _Bool is better because that lets the compiler do its magic.
>>>I took the earlier patch and completed it, switching over to int
>>>use in place of boolean_t in the few places it used - I'll merge
>>>that at some point, when its had enough testing.
>>>
>>>
>>>
>>Is that set in stone? Or is there a chance to (in my opinion) improve
>>the readability, by setting the variables to their real type.
>>
>>
>
>Nothings completely "set in stone" ... anyone can (and does) offer
>their own opinion. The opinion of people who a/ read and write XFS
>code alot and b/ test their changes, is alot more interesting than
>the opinion of those who don't, however.
>
>
Of course! :) No critisism intended.
Just the notion: "your" guys was the ones to make those to boolean(_t),
and now you seem to want to patch them away because I tried to make them
more general.
>In reality, from an XFS point of view, there are so few uses of the
>local boolean_t and so little value from it, that it really is just
>not worth getting involved in the pending bool code churn IMO (I see
>72 definitions of TRUE and FALSE in a recent mainline tree, so you
>have your work cut out for you...).
>
>
So, is the:
B_FALSE -> false
B_TRUE -> true
ok by you?
>"int needflush;" is just as readable (some would argue moreso) as
>"bool needflush;" and thats pretty much the level of use in XFS -
>
>
How are you sure "needflush" is, for example, not a counter?
>and we're using the "int" form in so many other places anyway...
>but, I'll see what the rest of the XFS folks think and take it from
>there.
>
>
Ok
>cheers.
>
>
cu
|