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.
On 28/08/06, Christoph Hellwig <[email protected]> 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 <[email protected]>
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
>> 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
--
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
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
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 <[email protected]>
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
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 <[email protected]>
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
On Mon, 28 Aug 2006 10:32:02 +0100
Christoph Hellwig <[email protected]> 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.
Andrew Morton wrote:
> On Mon, 28 Aug 2006 10:32:02 +0100
> Christoph Hellwig <[email protected]> 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
>> 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
--
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 <[email protected]> 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/
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.
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.
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.
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.
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/
>> > 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
--
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
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 [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
>> 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
--
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?
On Tue, 29 Aug 2006 12:45:02 +0100
Christoph Hellwig <[email protected]> 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.
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
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