Re: Conversion to generic boolean

Re: Conversion to generic boolean

[Christoph Hellwig]

On Sat, Aug 26, 2006 at 05:24:42AM +0200, Richard Knutsson wrote:
> Hello
> 
> Just would like to ask if you want patches for:

Total NACK to any of this boolean ididocy.  I very much hope you didn't
get the impression you actually have a chance to get this merged.

> 
> * (Most importent, may introduce bugs if left alone)
> Fixing boolean checking, ex:
> if (bool == FALSE)
> to
> if (!bool)

this one of course makes sense, but please do it without introducing
any boolean type.  Getting rid of all the TRUE/FALSE defines and converting
all scsi drivers to classic C integer as boolean semantics would be
very welcome janitorial work.

Re: Conversion to generic boolean

[Jesper Juhl]

On 28/08/06, Christoph Hellwig <hch@infradead.org> wrote:
> On Sat, Aug 26, 2006 at 05:24:42AM +0200, Richard Knutsson wrote:
> > Hello
> >
> > Just would like to ask if you want patches for:
>
> Total NACK to any of this boolean ididocy.  I very much hope you didn't
> get the impression you actually have a chance to get this merged.
>
> >
> > * (Most importent, may introduce bugs if left alone)
> > Fixing boolean checking, ex:
> > if (bool == FALSE)
> > to
> > if (!bool)
>
> this one of course makes sense, but please do it without introducing
> any boolean type.  Getting rid of all the TRUE/FALSE defines and converting
> all scsi drivers to classic C integer as boolean semantics would be
> very welcome janitorial work.
>
If you'll take such patches I'd be willing to clean up a few drivers..
 Any specific ones you'd like me to start with?

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Conversion to generic boolean

[Christoph Hellwig]

On Mon, Aug 28, 2006 at 11:45:21AM +0200, Jesper Juhl wrote:
> If you'll take such patches I'd be willing to clean up a few drivers..
> Any specific ones you'd like me to start with?

Everything under drivers/scsi/ would be nice, especially as there are
a lot with their own TRUE/FALSE definitons there.

Re: Conversion to generic boolean

[Jan Engelhardt]

>> Just would like to ask if you want patches for:
>
>Total NACK to any of this boolean ididocy.  I very much hope you didn't
>get the impression you actually have a chance to get this merged.
>
>> * (Most importent, may introduce bugs if left alone)
>> Fixing boolean checking, ex:
>> if (bool == FALSE)
>> to
>> if (!bool)
>
>this one of course makes sense, but please do it without introducing
>any boolean type.  Getting rid of all the TRUE/FALSE defines and converting
>all scsi drivers to classic C integer as boolean semantics would be
>very welcome janitorial work.

I don't get it. You object to the 'idiocy' 
(http://lkml.org/lkml/2006/7/27/281), but find the x==FALSE -> !x 
a good thing?


Jan Engelhardt
-- 

Re: Conversion to generic boolean

[Bernd Petrovitsch]

On Mon, 2006-08-28 at 12:58 +0200, Jan Engelhardt wrote:
> >> Just would like to ask if you want patches for:
> >
> >Total NACK to any of this boolean ididocy.  I very much hope you didn't
> >get the impression you actually have a chance to get this merged.
> >
> >> * (Most importent, may introduce bugs if left alone)
> >> Fixing boolean checking, ex:
> >> if (bool == FALSE)
> >> to
> >> if (!bool)
> >
> >this one of course makes sense, but please do it without introducing
> >any boolean type.  Getting rid of all the TRUE/FALSE defines and converting
> >all scsi drivers to classic C integer as boolean semantics would be
> >very welcome janitorial work.
> 
> I don't get it. You object to the 'idiocy' 
> (http://lkml.org/lkml/2006/7/27/281), but find the x==FALSE -> !x 
> a good thing?

If the "if (x == FALSE) { ... }" would be a good thing, why don't we
write "if ((x == FALSE) == TRUE) { ... }"?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Conversion to generic boolean

[Richard Knutsson]

Jan Engelhardt wrote:

>>>Just would like to ask if you want patches for:
>>>      
>>>
>>Total NACK to any of this boolean ididocy.  I very much hope you didn't
>>get the impression you actually have a chance to get this merged.
>>
>>    
>>
>>>* (Most importent, may introduce bugs if left alone)
>>>Fixing boolean checking, ex:
>>>if (bool == FALSE)
>>>to
>>>if (!bool)
>>>      
>>>
>>this one of course makes sense, but please do it without introducing
>>any boolean type.  Getting rid of all the TRUE/FALSE defines and converting
>>all scsi drivers to classic C integer as boolean semantics would be
>>very welcome janitorial work.
>>    
>>
>
>I don't get it. You object to the 'idiocy' 
>(http://lkml.org/lkml/2006/7/27/281), but find the x==FALSE -> !x 
>a good thing?
>  
>
That is error-prone. Not "==FALSE" but what happens if x is (for some 
reason) not 1 and then "if (x==TRUE)". There has been suggestions of doing:
if (x != FALSE)
or
if (!x == !TRUE)
but a simple "if (x)" is (in my opinion) the correct way.

Then that there is some objections booleans not being the "classical 
C"-way, is another story.

>Jan Engelhardt
>  
>
Richard Knutsson

Re: Conversion to generic boolean

[Nicholas Miell]

On Mon, 2006-08-28 at 14:17 +0200, Richard Knutsson wrote:
> Jan Engelhardt wrote:
> 
> >>>Just would like to ask if you want patches for:
> >>>      
> >>>
> >>Total NACK to any of this boolean ididocy.  I very much hope you didn't
> >>get the impression you actually have a chance to get this merged.
> >>
> >>    
> >>
> >>>* (Most importent, may introduce bugs if left alone)
> >>>Fixing boolean checking, ex:
> >>>if (bool == FALSE)
> >>>to
> >>>if (!bool)
> >>>      
> >>>
> >>this one of course makes sense, but please do it without introducing
> >>any boolean type.  Getting rid of all the TRUE/FALSE defines and converting
> >>all scsi drivers to classic C integer as boolean semantics would be
> >>very welcome janitorial work.
> >>    
> >>
> >
> >I don't get it. You object to the 'idiocy' 
> >(http://lkml.org/lkml/2006/7/27/281), but find the x==FALSE -> !x 
> >a good thing?
> >  
> >
> That is error-prone. Not "==FALSE" but what happens if x is (for some 
> reason) not 1 and then "if (x==TRUE)".

If you're using _Bool, that isn't possible. (Except at the boundaries
where you have to validate untrusted data -- and the compiler makes that
more difficult, because it "knows" that a _Bool can only be 0 or 1 and
therefore your check to see if it's not 0 or 1 can "safely" be
eliminated.)

-- 
Nicholas Miell <nmiell@comcast.net>

Re: Conversion to generic boolean

[Richard Knutsson]

Nicholas Miell wrote:

>On Mon, 2006-08-28 at 14:17 +0200, Richard Knutsson wrote:
>  
>
>>Jan Engelhardt wrote:
>>
>>    
>>
>>>>>Just would like to ask if you want patches for:
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Total NACK to any of this boolean ididocy.  I very much hope you didn't
>>>>get the impression you actually have a chance to get this merged.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>* (Most importent, may introduce bugs if left alone)
>>>>>Fixing boolean checking, ex:
>>>>>if (bool == FALSE)
>>>>>to
>>>>>if (!bool)
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>this one of course makes sense, but please do it without introducing
>>>>any boolean type.  Getting rid of all the TRUE/FALSE defines and converting
>>>>all scsi drivers to classic C integer as boolean semantics would be
>>>>very welcome janitorial work.
>>>>   
>>>>
>>>>        
>>>>
>>>I don't get it. You object to the 'idiocy' 
>>>(http://lkml.org/lkml/2006/7/27/281), but find the x==FALSE -> !x 
>>>a good thing?
>>> 
>>>
>>>      
>>>
>>That is error-prone. Not "==FALSE" but what happens if x is (for some 
>>reason) not 1 and then "if (x==TRUE)".
>>    
>>
>
>If you're using _Bool, that isn't possible. (Except at the boundaries
>where you have to validate untrusted data -- and the compiler makes that
>more difficult, because it "knows" that a _Bool can only be 0 or 1 and
>therefore your check to see if it's not 0 or 1 can "safely" be
>eliminated.)
>  
>
Yes, true. But there is no _Bool's in the kernel (linus-git), only one 
in script/.

Richard Knutsson

Re: Conversion to generic boolean

[Nicholas Miell]

On Mon, 2006-08-28 at 22:55 +0200, Richard Knutsson wrote:
> Nicholas Miell wrote:
> 
> >On Mon, 2006-08-28 at 14:17 +0200, Richard Knutsson wrote: 
> >
> >>Jan Engelhardt wrote:
> >>    
> >>
> >>>>>Just would like to ask if you want patches for:
> >>>>>         
> >>>>>
> >>>>Total NACK to any of this boolean ididocy.  I very much hope you didn't
> >>>>get the impression you actually have a chance to get this merged.
> >>>>
> >>>>
> >>>>>* (Most importent, may introduce bugs if left alone)
> >>>>>Fixing boolean checking, ex:
> >>>>>if (bool == FALSE)
> >>>>>to
> >>>>>if (!bool)
> >>>>>          
> >>>>>
> >>>>this one of course makes sense, but please do it without introducing
> >>>>any boolean type.  Getting rid of all the TRUE/FALSE defines and converting
> >>>>all scsi drivers to classic C integer as boolean semantics would be
> >>>>very welcome janitorial work.
> >>>>   
> >>>>
> >>>I don't get it. You object to the 'idiocy' 
> >>>(http://lkml.org/lkml/2006/7/27/281), but find the x==FALSE -> !x 
> >>>a good thing?
> >>>     
> >>>
> >>That is error-prone. Not "==FALSE" but what happens if x is (for some 
> >>reason) not 1 and then "if (x==TRUE)".
> >>    
> >
> >If you're using _Bool, that isn't possible. (Except at the boundaries
> >where you have to validate untrusted data -- and the compiler makes that
> >more difficult, because it "knows" that a _Bool can only be 0 or 1 and
> >therefore your check to see if it's not 0 or 1 can "safely" be
> >eliminated.)
> >  
> >
> Yes, true. But there is no _Bool's in the kernel (linus-git), only one 
> in script/.
> 

Sorry, I was under the impression that the purpose of the generic
boolean patch was to switch the kernel over to C's generic boolean.


-- 
Nicholas Miell <nmiell@comcast.net>

Re: Conversion to generic boolean

[Richard Knutsson]

Nicholas Miell wrote:

>On Mon, 2006-08-28 at 22:55 +0200, Richard Knutsson wrote:
>  
>
>>Nicholas Miell wrote:
>>
>>    
>>
>>>On Mon, 2006-08-28 at 14:17 +0200, Richard Knutsson wrote: 
>>>
>>>      
>>>
>>>>Jan Engelhardt wrote:
>>>>   
>>>>
>>>>        
>>>>
>>>>>>>Just would like to ask if you want patches for:
>>>>>>>        
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>Total NACK to any of this boolean ididocy.  I very much hope you didn't
>>>>>>get the impression you actually have a chance to get this merged.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>* (Most importent, may introduce bugs if left alone)
>>>>>>>Fixing boolean checking, ex:
>>>>>>>if (bool == FALSE)
>>>>>>>to
>>>>>>>if (!bool)
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>this one of course makes sense, but please do it without introducing
>>>>>>any boolean type.  Getting rid of all the TRUE/FALSE defines and converting
>>>>>>all scsi drivers to classic C integer as boolean semantics would be
>>>>>>very welcome janitorial work.
>>>>>>  
>>>>>>
>>>>>>            
>>>>>>
>>>>>I don't get it. You object to the 'idiocy' 
>>>>>(http://lkml.org/lkml/2006/7/27/281), but find the x==FALSE -> !x 
>>>>>a good thing?
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>>That is error-prone. Not "==FALSE" but what happens if x is (for some 
>>>>reason) not 1 and then "if (x==TRUE)".
>>>>   
>>>>        
>>>>
>>>If you're using _Bool, that isn't possible. (Except at the boundaries
>>>where you have to validate untrusted data -- and the compiler makes that
>>>more difficult, because it "knows" that a _Bool can only be 0 or 1 and
>>>therefore your check to see if it's not 0 or 1 can "safely" be
>>>eliminated.)
>>> 
>>>
>>>      
>>>
>>Yes, true. But there is no _Bool's in the kernel (linus-git), only one 
>>in script/.
>>
>>    
>>
>
>Sorry, I was under the impression that the purpose of the generic
>boolean patch was to switch the kernel over to C's generic boolean.
>  
>
Oh no, my bad. Well, at least some like to do it (including me).
But you really have to bend it to make _Bool take another value then 0/1.
Regarding "== FALSE" and co., there is still no reason for them, other 
then bloater the code.

Richard Knutsson

Re: Conversion to generic boolean

[Christoph Hellwig]

On Mon, Aug 28, 2006 at 12:15:40PM -0700, Nicholas Miell wrote:
> > That is error-prone. Not "==FALSE" but what happens if x is (for some 
> > reason) not 1 and then "if (x==TRUE)".
> 
> If you're using _Bool, that isn't possible. (Except at the boundaries
> where you have to validate untrusted data -- and the compiler makes that
> more difficult, because it "knows" that a _Bool can only be 0 or 1 and
> therefore your check to see if it's not 0 or 1 can "safely" be
> eliminated.)

gcc lets you happily assign any integer value to bool/_Bool, so unless
you write sparse support for actually checking things there's not the
slightest advantage in value range checking.

Re: Conversion to generic boolean

[Jan Engelhardt]

>> > That is error-prone. Not "==FALSE" but what happens if x is (for some 
>> > reason) not 1 and then "if (x==TRUE)".
>> 
>> If you're using _Bool, that isn't possible. (Except at the boundaries
>> where you have to validate untrusted data -- and the compiler makes that
>> more difficult, because it "knows" that a _Bool can only be 0 or 1 and
>> therefore your check to see if it's not 0 or 1 can "safely" be
>> eliminated.)
>
>gcc lets you happily assign any integer value to bool/_Bool, so unless

But, it coerces the rvalue into 0 or 1, which may be a gain.

>you write sparse support for actually checking things there's not the
>slightest advantage in value range checking.


Jan Engelhardt
-- 

Re: Conversion to generic boolean

[Peter Williams]

Jan Engelhardt wrote:
>>>> That is error-prone. Not "==FALSE" but what happens if x is (for some 
>>>> reason) not 1 and then "if (x==TRUE)".
>>> If you're using _Bool, that isn't possible. (Except at the boundaries
>>> where you have to validate untrusted data -- and the compiler makes that
>>> more difficult, because it "knows" that a _Bool can only be 0 or 1 and
>>> therefore your check to see if it's not 0 or 1 can "safely" be
>>> eliminated.)
>> gcc lets you happily assign any integer value to bool/_Bool, so unless
> 
> But, it coerces the rvalue into 0 or 1, which may be a gain.

Actually, it's not coercion.  It's the result of evaluating the value as 
a boolean expression.

> 
>> you write sparse support for actually checking things there's not the
>> slightest advantage in value range checking.
> 
> 
> Jan Engelhardt


-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: Conversion to generic boolean

[Jan Engelhardt]

>> But, it coerces the rvalue into 0 or 1, which may be a gain.
>
> Actually, it's not coercion.  It's the result of evaluating the value as a
> boolean expression.

Don't be such a linguist :p



Jan Engelhardt
-- 

Re: Conversion to generic boolean

[Alan Cox]

Ar Maw, 2006-08-29 am 12:41 +0100, ysgrifennodd Christoph Hellwig:
> gcc lets you happily assign any integer value to bool/_Bool, so unless
> you write sparse support for actually checking things there's not the
> slightest advantage in value range checking.

Not the case: gcc allows you to assign 0 or 1 to an _Bool type object.
When you are "assigning" integers you are merely seeing implicit casting
before the assignment.

Try   int a = 4; _Bool b = a; int c = b; printf("%d\n", c);

Alan

Re: Conversion to generic boolean

[Andrew Morton]

On Mon, 28 Aug 2006 10:32:02 +0100
Christoph Hellwig <hch@infradead.org> wrote:

> On Sat, Aug 26, 2006 at 05:24:42AM +0200, Richard Knutsson wrote:
> > Hello
> > 
> > Just would like to ask if you want patches for:
> 
> Total NACK to any of this boolean ididocy.  I very much hope you didn't
> get the impression you actually have a chance to get this merged.

I was kinda planning on merging it ;)

I can't say that I'm in love with the patches, but they do improve the
situation.

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.

Re: Conversion to generic boolean

[Nick Piggin]

Andrew Morton wrote:
> On Mon, 28 Aug 2006 10:32:02 +0100
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> 
>>On Sat, Aug 26, 2006 at 05:24:42AM +0200, Richard Knutsson wrote:
>>
>>>Hello
>>>
>>>Just would like to ask if you want patches for:
>>
>>Total NACK to any of this boolean ididocy.  I very much hope you didn't
>>get the impression you actually have a chance to get this merged.
> 
> 
> I was kinda planning on merging it ;)
> 
> I can't say that I'm in love with the patches, but they do improve the
> situation.
> 
> 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.

Well... we are programming in C here, aren't we ;)

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: Conversion to generic boolean

[Jan Engelhardt]

>> I was kinda planning on merging it ;)
>> 
>> I can't say that I'm in love with the patches, but they do improve the
>> situation.
>> 
>> 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.
>
> Well... we are programming in C here, aren't we ;)

I like it for the annotation we get.

	int fluff;
	if(fluff == 0)

This does not tell if fluff is an integer or a boolean (that is, what the
programmer intended to do -- not the 'int' the compiler sees).
If it had been if(!fluff), it would give a hint, but a lot of places also have
!x where x really is intended to be an integer (and should have been x==0 or
y==NULL resp.)


Jan Engelhardt
-- 

Re: Conversion to generic boolean

[Dmitry Torokhov]

On Tuesday 29 August 2006 01:58, Jan Engelhardt wrote:
> 
> >> I was kinda planning on merging it ;)
> >> 
> >> I can't say that I'm in love with the patches, but they do improve the
> >> situation.
> >> 
> >> 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.
> >
> > Well... we are programming in C here, aren't we ;)
> 
> I like it for the annotation we get.
> 
> 	int fluff;
> 	if(fluff == 0)
> 
> This does not tell if fluff is an integer or a boolean (that is, what the
> programmer intended to do -- not the 'int' the compiler sees).
> If it had been if(!fluff), it would give a hint, but a lot of places also have
> !x where x really is intended to be an integer (and should have been x==0 or
> y==NULL resp.)
>

Bool would not help much either unless declaration is immediately follows
use. I like Alan Sterns proposal ofencode return value in function name
better - actions should always return < 0/0 and predicates should always
be boolean equivalent.
 
-- 
Dmitry

Re: Conversion to generic boolean

[Pavel Machek]

Hi!

> > I like it for the annotation we get.
> > 
> > 	int fluff;
> > 	if(fluff == 0)
> > 
> > This does not tell if fluff is an integer or a boolean (that is, what the
> > programmer intended to do -- not the 'int' the compiler sees).
> > If it had been if(!fluff), it would give a hint, but a lot of places also have
> > !x where x really is intended to be an integer (and should have been x==0 or
> > y==NULL resp.)
> >
> 
> Bool would not help much either unless declaration is immediately follows
> use. I like Alan Sterns proposal ofencode return value in function name
> better - actions should always return < 0/0 and predicates should always
> be boolean equivalent.

Sounds very reasonable. Even today, 90% of code follows that
convention. Perhaps adding it to codingstyle would help?

-- 
Thanks for all the (sleeping) penguins.

-- 
VGER BF report: H 0.254977

Re: Conversion to generic boolean

[Anton Altaparmakov]

On Tue, 2006-08-29 at 11:15 +1000, Nick Piggin wrote:
> Andrew Morton wrote:
> > On Mon, 28 Aug 2006 10:32:02 +0100
> > Christoph Hellwig <hch@infradead.org> wrote:
> > 
> > 
> >>On Sat, Aug 26, 2006 at 05:24:42AM +0200, Richard Knutsson wrote:
> >>
> >>>Hello
> >>>
> >>>Just would like to ask if you want patches for:
> >>
> >>Total NACK to any of this boolean ididocy.  I very much hope you didn't
> >>get the impression you actually have a chance to get this merged.
> > 
> > 
> > I was kinda planning on merging it ;)
> > 
> > I can't say that I'm in love with the patches, but they do improve the
> > situation.
> > 
> > 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.
> 
> Well... we are programming in C here, aren't we ;)

Not sure whether this is meant in favour of one or the other but we are
not programming in C strictly speaking but in C99+gccisms and C99
includes _Bool...

ps. I am definitely in favour of a kernel wide boolean type and will
certainly refuse any patches that remove the NTFS boolean type and
replace it with an open-coded 0/1...  I can only imagine that most other
maintainers who presently define their own boolen types will do the
same...

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: Conversion to generic boolean

[Christoph Hellwig]

On Tue, Aug 29, 2006 at 08:29:38AM +0100, Anton Altaparmakov wrote:
> Not sure whether this is meant in favour of one or the other but we are
> not programming in C strictly speaking but in C99+gccisms and C99
> includes _Bool...

as does it include float, double, _Complex and other things we don't use.

Re: Conversion to generic boolean

[Anton Altaparmakov]

On Tue, 2006-08-29 at 12:46 +0100, Christoph Hellwig wrote:
> On Tue, Aug 29, 2006 at 08:29:38AM +0100, Anton Altaparmakov wrote:
> > Not sure whether this is meant in favour of one or the other but we are
> > not programming in C strictly speaking but in C99+gccisms and C99
> > includes _Bool...
> 
> as does it include float, double, _Complex and other things we don't use.

We don't use those for completely different reasons...  But you knew
that already...

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: Conversion to generic boolean

[Christoph Hellwig]

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

Re: Conversion to generic boolean

[Richard Knutsson]

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?

Re: Conversion to generic boolean

[Andrew Morton]

On Tue, 29 Aug 2006 12:45:02 +0100
Christoph Hellwig <hch@infradead.org> 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.  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.

Not really.  bool/true/false have readability advantages over int/1/0.

Re: Conversion to generic boolean

[linux]

I have to say, I think <stdbool.h> is a Very Good Thing.

There are actually two stnadard C conventions for boolean return codes:
1) 0 = false, 1 = true
2) 0 = success, -1 = failure (or generally >= 0 and < 0)

I generally like true = success, false = failure, which can require some
edits of all the call sites if converting from the second convention.

But in either case, I'd much rather have a function declated "bool"
than "int", becuase then I *know* there are only two return values,
and nobody has invented a return value of 2 for some reason.

And, as others have noticed, the compiler can optimize using that
information, too.

(Conversely, if the convention to use bool where possible is
well-established, then if you see "int", you *know* there are more than
two possible return values.)


I'm all for just #include <stdbool.h> and use "bool", "true" and "false".