linux-kernel - Re: Conversion to 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: <44F44AB8.7090204@student.ltu.se>
Date:	Tue, 29 Aug 2006 16:10:00 +0200
From:	Richard Knutsson <ricknu-0@...dent.ltu.se>
To:	Christoph Hellwig <hch@...radead.org>
CC:	Andrew Morton <akpm@...l.org>, James.Bottomley@...elEye.com,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Conversion to generic boolean

Christoph Hellwig wrote:

>On Mon, Aug 28, 2006 at 05:18:04PM -0700, Andrew Morton wrote:
>  
>
>>At present we have >50 different definitions of TRUE and gawd knows how
>>many private implementations of various flavours of bool.
>>
>>In that context, Richard's approach of giving the kernel a single
>>implementation of bool/true/false and then converting things over to use it
>>makes sense.  The other approach would be to go through and nuke the lot,
>>convert them to open-coded 0/1.
>>
>>I'm not particularly fussed either way, really.  But the present situation
>>is nuts.
>>    
>>
>
>Let's start to kill all those utterly silly if (x == true) and if (x == false)
>into if (x) and if (!x) and pospone the type decision.
>
Ok, sounds like a good idea. But I think those who already use 
boolean-type can/should be changed. Just have to stop myself of 
converting "boolean" int's.

>                                                        Adding a bool type
>only makes sense if we have any kind of static typechecking that no one
>ever assign an invalid type to it.
>  
>
Do not agree on this thou. Of couse it is something to strive for, but 
_Bool is using the same boolean-logic as C always used:
0 is false, otherwise it is true
so blaming _Bool for using this seem a bit odd. Also, do you mean to 
approve changing the return-type of all the functions who returns a 
boolean but uses an integer?

-
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/