linux-kernel - Re: [PATCH 2.6.18-rc4-mm3 2/2] fs/xfs: Converting into generic boolean

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44FD71C6.20006@student.ltu.se>
Date:	Tue, 05 Sep 2006 14:47:02 +0200
From:	Richard Knutsson <ricknu-0@...dent.ltu.se>
To:	Nathan Scott <nathans@....com>
CC:	akpm@...l.org, xfs-masters@....sgi.com, xfs@....sgi.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.18-rc4-mm3 2/2] fs/xfs: Converting into generic boolean

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/