Re: RFC: booleans and the kernel

Re: RFC: booleans and the kernel

[Helge Hafting]

Jeff Garzik wrote:
> 
> Oliver Xymoron wrote:
> > On Thu, 24 Jan 2002, Jeff Garzik wrote:
> > > Where variables are truly boolean use of a bool type makes the
> > > intentions of the code more clear.  And it also gives the compiler a
> > > slightly better chance to optimize code [I suspect].
> >
> > Unlikely. The compiler can already figure this sort of thing out from
> > context.
> 
> X, true, and false are of type int.
> If one tests X==false and then later on tests X==true, how does the
> compiler know the entire domain has been tested?  With a boolean, it

Why would anyone want to write   if (X==false) or if (X==true) ?
It is the "beginner's mistake" way of writing code.  Then people learn,
and write if (X) or if (!X).  Comparing to true/false is silly.
Nobody writes  if ( (a==b) == true) so why do it in the simpler cases?

> would.  Or a switch statement... if both true and false are covered,
A switch statement on a boolean value is stupid.  Use if - there
is only two cases.

Helge Hafting

Re: RFC: booleans and the kernel

[Jamie Lokier]

Helge Hafting wrote:
> Why would anyone want to write   if (X==false) or if (X==true) ?
> It is the "beginner's mistake" way of writing code.  Then people learn,
> and write if (X) or if (!X).  Comparing to true/false is silly.
> Nobody writes  if ( (a==b) == true) so why do it in the simpler cases?

I usually without the == in these cases:

  if (pointer)  // test for non-0.
  if (condition)
  if (condition-valued-variable)

but not in these (although I am not very consistent):

  if (integer != 0)
  if (char != 0)

When using bool, I'm happy to write "if (X)" where X is a truth value
indicating a condition that has been tested, but if X were used as an
enumeration of truth values e.g. as in a theorem prover or a logic
simulator, I would tend to write ==, for example:

  if (X == true && ptr && *ptr > 1)

The point being to illustrate the intent of the test (i.e. is it a
boolean test or a comparison against a point in a range of values), not
simply for it to be semantically correct.

Just to break that rule, however, if p were a pointer and x were an
integer, I would write:

  x = (p != 0);

rather than

  x = p;

:-)

enjoy,
-- Jamie

Re: RFC: booleans and the kernel

[Mark Zealey]

On Sat, Jan 26, 2002 at 03:08:41AM +0000, Jamie Lokier wrote:

> Helge Hafting wrote:
> > Why would anyone want to write   if (X==false) or if (X==true) ?
> > It is the "beginner's mistake" way of writing code.  Then people learn,
> > and write if (X) or if (!X).  Comparing to true/false is silly.
> > Nobody writes  if ( (a==b) == true) so why do it in the simpler cases?
> 
> I usually without the == in these cases:
> 
>   if (pointer)  // test for non-0.

Huh? I thought we were talking about C here, // in C is an abomination, use /*
*/ :-)

> Just to break that rule, however, if p were a pointer and x were an
> integer, I would write:
> 
>   x = (p != 0);

Heard about NULL ?

> rather than
> 
>   x = p;

Because that would give a compile error...

-- 

Mark Zealey
mark@zealos.org
mark@itsolve.co.uk

UL++++>$ G!>(GCM/GCS/GS/GM) dpu? s:-@ a16! C++++>$ P++++>+++++$ L+++>+++++$
!E---? W+++>$ N- !o? !w--- O? !M? !V? !PS !PE--@ PGP+? r++ !t---?@ !X---?
!R- b+ !tv b+ DI+ D+? G+++ e>+++++ !h++* r!-- y--

(www.geekcode.com)

Re: RFC: booleans and the kernel

[Jamie Lokier]

Mark Zealey wrote:
> > Just to break that rule, however, if p were a pointer and x were an
> > integer, I would write:
> > 
> >   x = (p != 0);
> 
> Heard about NULL ?

I prefer 0, thanks.  NULL has header file portability problems.

-- Jamie

Re: RFC: booleans and the kernel

[Gábor Lénárt]

On Sat, Jan 26, 2002 at 03:08:41AM +0000, Jamie Lokier wrote:
> Helge Hafting wrote:
> > Why would anyone want to write   if (X==false) or if (X==true) ?
> > It is the "beginner's mistake" way of writing code.  Then people learn,
> > and write if (X) or if (!X).  Comparing to true/false is silly.
> > Nobody writes  if ( (a==b) == true) so why do it in the simpler cases?
> 
> I usually without the == in these cases:
> 
>   if (pointer)  // test for non-0.
>   if (condition)
>   if (condition-valued-variable)
> 
> but not in these (although I am not very consistent):

Khmmm please enlighten me ...

>   if (X == true && ptr && *ptr > 1)

Why? Simply use for example type 'char' as boolean value. Let's say
0 means false and other value is true.

So:

if (x) printf("true");

or

if (!x) printf("false");

Why do you want to overcomplicate?

Even:

x=a>b;
if (x) printf("A is greater than B");

ONE thing which is best in C is the less strictly type rules eg you
can use 'char' to store eg c='A' or c=2.
Hey guys, C was designed to write an OS it's not something other ...

- Gábor

Re: RFC: booleans and the kernel

[Jamie Lokier]

Gábor Lénárt wrote:
> Khmmm please enlighten me ...
> 
> >   if (X == true && ptr && *ptr > 1)
> 
> Why? Simply use for example type 'char' as boolean value. Let's say
> 0 means false and other value is true.
> 
> So:
> 
> if (x) printf("true");
> or
> if (!x) printf("false");
> 
> Why do you want to overcomplicate?

If the variable holds a boolean in the C language, fair enough but if
it's being used as a range in a truth-value system of _another_
language, i.e. it simply _represents_ a truth value, I would write it
differently.

If it were a theorem proving paper, the different kinds of variable
would have a different font or colour :-)

> x=a>b;
> if (x) printf("A is greater than B");
> 
> ONE thing which is best in C is the less strictly type rules eg you
> can use 'char' to store eg c='A' or c=2.

You seem to have missed the point.  We _know_ the C language rules.  I
agree that non-strict typeing is quite useful, although C is in fact
quite strict.  Lisp has far less strict typing :-)

> Hey guys, C was designed to write an OS it's not something other ...

Perhaps, but it's pretty useful for something other.

-- Jamie

Re: RFC: booleans and the kernel

[Ben Bridgwater]

Rick Stevens wrote:

 > Granted.  "if (x)" is true if "x" is non-zero, regardless of type and
 > shoudn't even generate a warning if "x" is scalar.

Surely the major point of using the compiler's _Bool would be for type 
safety -  if you only want readability then you may as well just use:

enum bool {true = 1, false = 0};

Now since C has historically utilized integer expressions for 
conditionals (with 0, !0 truth semantics), so it would be obnoxious to 
*unconditionally* make if (x) where x is non _Bool generate warnings, 
but IMO the whole point of using _Bool would be to then choose to turn 
on warnings for non _Bool conditionals, and to suppress warnings one 
would then need to be explicit about intentions by writing code such as:

if ((_Bool) (x = y)) ;

and hopefully if one accidently wrote:

if ((_Bool) x = y) ; /* int x, y */

then the compiler would warn that you probably didn't really mean that, 
since it means:

if ((_Bool) (x = (int) (_Bool) y)) ;

Which would have converted your y to _Bool (0/1) before assigning it to x.

Ben

P.S. I'm not on the list - please CC any response to me if you want a reply.

Re: RFC: booleans and the kernel

[Thomas Hood]

Jeff Garzik wrote:
> A small issue...

... bound therefore to generate the most discussion ...

> C99 introduced _Bool as a builtin type.  The gcc patch for
> it went into cvs around Dec 2000.  Any objections to
> propagating this type and usage of 'true' and 'false' around
> the kernel?

What concerns me is the question of casting.  Will truth always
cast to integer value 1 and falsehood always cast to integer
value 0, and vice versa?  If so then the bool type is a lot
like a "bit" type would be if C had one, i.e., a very short
integer variable limited to the values 0 and 1.  If the casts
are not guaranteed then bool is a lot like an enumerated type
where the compiler is free to choose whatever representations
it wants for truth and falsehood.

I assume the casts are guaranteed.  E.g., I take it that the
result of a logical comparison is considered to be of type
bool, but that the following will increment val by 1 if a > b
    val += (a > b)

In that case, perhaps it would be more perspicuous to define
a "bit" type rather than a "bool" type, and to use 0 and 1 as
its values rather than 'true' and 'false'.  (A "bit" type 
would have all the advantages mentioned earlier by Peter Anvin
http://marc.theaimsgroup.com/?l=linux-kernel&m=101191106124169&w=2 .)

--
Thomas Hood

Re: RFC: booleans and the kernel

[Xavier Bestel]

le ven 25-01-2002 à 12:28, Thomas Hood a écrit :

> In that case, perhaps it would be more perspicuous to define
> a "bit" type rather than a "bool" type, and to use 0 and 1 as
> its values rather than 'true' and 'false'.  (A "bit" type 
> would have all the advantages mentioned earlier by Peter Anvin
> http://marc.theaimsgroup.com/?l=linux-kernel&m=101191106124169&w=2 .)

in the hypothetical 'bit type' case:

bit n;
n = 2;
printf("n = %d\n", n);

guess what ? n = 0

	Xav

RFC: booleans and the kernel

[Jeff Garzik]

A small issue... 

C99 introduced _Bool as a builtin type.  The gcc patch for it went into
cvs around Dec 2000.  Any objections to propagating this type and usage
of 'true' and 'false' around the kernel?

Where variables are truly boolean use of a bool type makes the
intentions of the code more clear.  And it also gives the compiler a
slightly better chance to optimize code [I suspect].

Actually I prefer 'bool' to '_Bool', if this becomes a kernel standard.

	Jeff


-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: RFC: booleans and the kernel

[Anton Altaparmakov]

At 17:42 24/01/02, Jeff Garzik wrote:
>A small issue...
>
>C99 introduced _Bool as a builtin type.  The gcc patch for it went into
>cvs around Dec 2000.  Any objections to propagating this type and usage
>of 'true' and 'false' around the kernel?
>
>Where variables are truly boolean use of a bool type makes the
>intentions of the code more clear.  And it also gives the compiler a
>slightly better chance to optimize code [I suspect].
>
>Actually I prefer 'bool' to '_Bool', if this becomes a kernel standard.

I would be in favour of this as it does make code more readable. I use it 
in ntfs tng quite a bit (but I just typedef a BOOL type myself).

If it is added, then _please_ don't use '_Bool', that's just sick... 
'bool', heck even 'BOOL' would be better than that!

Best regards,

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: RFC: booleans and the kernel

[Arnaldo Carvalho de Melo]

Em Thu, Jan 24, 2002 at 06:22:03PM +0000, Anton Altaparmakov escreveu:
> At 17:42 24/01/02, Jeff Garzik wrote:
> >Actually I prefer 'bool' to '_Bool', if this becomes a kernel standard.
> 
> I would be in favour of this as it does make code more readable. I use it 
> in ntfs tng quite a bit (but I just typedef a BOOL type myself).
> 
> If it is added, then _please_ don't use '_Bool', that's just sick... 
> 'bool', heck even 'BOOL' would be better than that!

I'd vote for bool, long are the days when I programmed COBOL in original
3270 terminals, heck it seems like it was in a previous life 8)

/me scratches head, I should go back and update the kernel janitor TODO
list with this...

- Arnaldo

Re: RFC: booleans and the kernel

[H. Peter Anvin]

Followup to:  <3C5047A2.1AB65595@mandrakesoft.com>
By author:    Jeff Garzik <jgarzik@mandrakesoft.com>
In newsgroup: linux.dev.kernel
>
> A small issue... 
> 
> C99 introduced _Bool as a builtin type.  The gcc patch for it went into
> cvs around Dec 2000.  Any objections to propagating this type and usage
> of 'true' and 'false' around the kernel?
> 
> Where variables are truly boolean use of a bool type makes the
> intentions of the code more clear.  And it also gives the compiler a
> slightly better chance to optimize code [I suspect].
> 
> Actually I prefer 'bool' to '_Bool', if this becomes a kernel standard.
> 

Noone is actually meant to use _Bool, except perhaps in header files.

#include <stdbool.h>

... then use "bool", "true", "false".

This is fine with me as long our version of stdbool.h contain the
appropriate ifdefs.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: RFC: booleans and the kernel

[Arnaldo Carvalho de Melo]

Em Thu, Jan 24, 2002 at 11:28:46AM -0800, H. Peter Anvin escreveu:
> Noone is actually meant to use _Bool, except perhaps in header files.
> 
> #include <stdbool.h>
 
perhaps we don't need another header, adding this instead to types.h.

> ... then use "bool", "true", "false".
> 
> This is fine with me as long our version of stdbool.h contain the
> appropriate ifdefs.

- Arnaldo

Re: RFC: booleans and the kernel

[H. Peter Anvin]

Arnaldo Carvalho de Melo wrote:

> Em Thu, Jan 24, 2002 at 11:28:46AM -0800, H. Peter Anvin escreveu:
> 
>>Noone is actually meant to use _Bool, except perhaps in header files.
>>
>>#include <stdbool.h>
>   
> perhaps we don't need another header, adding this instead to types.h.
> 


That's fine for the Linux kernel, of course, but the above was mostly for
reference -- it's the *intended* way to use these keywords (you have to
explicitly import these macros into the namespace, but using the
C++-compatible tokens is definitely the intention.)

	-hpa

Re: RFC: booleans and the kernel

[Arnaldo Carvalho de Melo]

Em Thu, Jan 24, 2002 at 11:43:48AM -0800, H. Peter Anvin escreveu:
> Arnaldo Carvalho de Melo wrote:
> > Em Thu, Jan 24, 2002 at 11:28:46AM -0800, H. Peter Anvin escreveu:
> >>Noone is actually meant to use _Bool, except perhaps in header files.
> >>#include <stdbool.h>
> >   
> > perhaps we don't need another header, adding this instead to types.h.
> 
> That's fine for the Linux kernel, of course, but the above was mostly for
> reference -- it's the *intended* way to use these keywords (you have to
> explicitly import these macros into the namespace, but using the
> C++-compatible tokens is definitely the intention.)

makes sense, I was just thinking about the kernel

- Arnaldo

Re: RFC: booleans and the kernel

[Ingo Oeser]

On Thu, Jan 24, 2002 at 05:34:37PM -0200, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 24, 2002 at 11:28:46AM -0800, H. Peter Anvin escreveu:
> > Noone is actually meant to use _Bool, except perhaps in header files.
> > 
> > #include <stdbool.h>
>  
> perhaps we don't need another header, adding this instead to types.h.

Since this is compiler specific, what about

#include <linux/compiler.h>

instead? So there would be only one file, the gcc experts
have to track for versions and features.

Regards

Ingo Oeser
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
     >>>   4. Chemnitzer Linux-Tag - 09.+10. Maerz 2002 <<<
              http://www.tu-chemnitz.de/linux/tag/

Re: RFC: booleans and the kernel

[Oliver Xymoron]

On Thu, 24 Jan 2002, Jeff Garzik wrote:

> A small issue...
>
> C99 introduced _Bool as a builtin type.  The gcc patch for it went into
> cvs around Dec 2000.  Any objections to propagating this type and usage
> of 'true' and 'false' around the kernel?

Ugh, no. C doesn't need booleans, neither do Perl or Python. This is a
sickness imported from _recent_ C++ by way of Java by way of Pascal. This
just complicates things.

> Where variables are truly boolean use of a bool type makes the
> intentions of the code more clear.  And it also gives the compiler a
> slightly better chance to optimize code [I suspect].

Unlikely. The compiler can already figure this sort of thing out from
context.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: RFC: booleans and the kernel

[Jeff Garzik]

Oliver Xymoron wrote:
> On Thu, 24 Jan 2002, Jeff Garzik wrote:
> > Where variables are truly boolean use of a bool type makes the
> > intentions of the code more clear.  And it also gives the compiler a
> > slightly better chance to optimize code [I suspect].
> 
> Unlikely. The compiler can already figure this sort of thing out from
> context.

X, true, and false are of type int.
If one tests X==false and then later on tests X==true, how does the
compiler know the entire domain has been tested?  With a boolean, it
would.  Or a switch statement... if both true and false are covered,
there is no need for a 'default'.  Similar arguments apply for
enumerated types.

-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: RFC: booleans and the kernel

[Oliver Xymoron]

On Thu, 24 Jan 2002, Jeff Garzik wrote:

> Oliver Xymoron wrote:
> > On Thu, 24 Jan 2002, Jeff Garzik wrote:
> > > Where variables are truly boolean use of a bool type makes the
> > > intentions of the code more clear.  And it also gives the compiler a
> > > slightly better chance to optimize code [I suspect].
> >
> > Unlikely. The compiler can already figure this sort of thing out from
> > context.
>
> X, true, and false are of type int.
> If one tests X==false and then later on tests X==true, how does the
> compiler know the entire domain has been tested?

Because you never test against X==true. You always test X!=false. This is
the C way.

> Or a switch statement... if both true and false are covered,
> there is no need for a 'default'.

Your cases are false and default.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: RFC: booleans and the kernel

[Jeff Garzik]

Oliver Xymoron wrote:
> Because you never test against X==true. You always test X!=false. This is
> the C way.

That is the theory, yes... :)

-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: RFC: booleans and the kernel

[Alexander Viro]

On Thu, 24 Jan 2002, Oliver Xymoron wrote:

> Because you never test against X==true. You always test X!=false. This is
> the C way.

ITYM "You always test X".

Re: RFC: booleans and the kernel

[Oliver Xymoron]

On Thu, 24 Jan 2002, Alexander Viro wrote:

> On Thu, 24 Jan 2002, Oliver Xymoron wrote:
>
> > Because you never test against X==true. You always test X!=false. This is
> > the C way.
>
> ITYM "You always test X".

I do indeed, but the bool crowd seems to like making the != explicit for
some reason.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: RFC: booleans and the kernel

[John Levon]

On Thu, Jan 24, 2002 at 02:25:25PM -0600, Oliver Xymoron wrote:

> I do indeed, but the bool crowd seems to like making the != explicit for some
> reason.

that's a ridiculous generalisation.

john

-- 
"ALL television is children's television."
	- Richard Adler 

Re: RFC: booleans and the kernel

[Alexander Viro]

On Thu, 24 Jan 2002, Jeff Garzik wrote:

> If one tests X==false and then later on tests X==true,

... one is a wanker.  (X == false) is not idiomatic. (!X) is.

Re: RFC: booleans and the kernel

[Richard B. Johnson]

On Thu, 24 Jan 2002, Oliver Xymoron wrote:

> On Thu, 24 Jan 2002, Jeff Garzik wrote:
> 
> > A small issue...
> >
> > C99 introduced _Bool as a builtin type.  The gcc patch for it went into
> > cvs around Dec 2000.  Any objections to propagating this type and usage
> > of 'true' and 'false' around the kernel?
> 
> Ugh, no. C doesn't need booleans, neither do Perl or Python. This is a
> sickness imported from _recent_ C++ by way of Java by way of Pascal. This
> just complicates things.
> 
> > Where variables are truly boolean use of a bool type makes the
> > intentions of the code more clear.  And it also gives the compiler a
> > slightly better chance to optimize code [I suspect].
> 
> Unlikely. The compiler can already figure this sort of thing out from
> context.

IFF the 'C' compiler code-generators start making better code, i.e.,
ORing a value already in a register, with itself and jumping on
condition, then bool will be helpful. Right now, I see tests against
numbers (like 0). This increases the code-size because the 0 is
in the instruction stream, plus the comparison of an immediate
value to a register value (on Intel) takes more CPU cycles.

So, if the compiler, knowing that bool can be only TRUE or
FALSE (implementation-defined 1 or 0), then it can probably
save a few CPU cycles. A good thing about a new type is that
you don't have to use it. Just like enumerated types, if you
don't like them, don't use them. Perfectly good code can be
written without them.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: RFC: booleans and the kernel

[Oliver Xymoron]

On Thu, 24 Jan 2002, Richard B. Johnson wrote:

> On Thu, 24 Jan 2002, Oliver Xymoron wrote:
>
> > On Thu, 24 Jan 2002, Jeff Garzik wrote:
> >
> > > A small issue...
> > >
> > > C99 introduced _Bool as a builtin type.  The gcc patch for it went into
> > > cvs around Dec 2000.  Any objections to propagating this type and usage
> > > of 'true' and 'false' around the kernel?
> >
> > Ugh, no. C doesn't need booleans, neither do Perl or Python. This is a
> > sickness imported from _recent_ C++ by way of Java by way of Pascal. This
> > just complicates things.
> >
> > > Where variables are truly boolean use of a bool type makes the
> > > intentions of the code more clear.  And it also gives the compiler a
> > > slightly better chance to optimize code [I suspect].
> >
> > Unlikely. The compiler can already figure this sort of thing out from
> > context.
>
> IFF the 'C' compiler code-generators start making better code, i.e.,
> ORing a value already in a register, with itself and jumping on
> condition, then bool will be helpful. Right now, I see tests against
> numbers (like 0). This increases the code-size because the 0 is
> in the instruction stream, plus the comparison of an immediate
> value to a register value (on Intel) takes more CPU cycles.

The compiler _will_ turn if(a==0) into a test of a with itself rather than
a comparison against a constant. Since PDP days, no doubt.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: RFC: booleans and the kernel

[Richard B. Johnson]

On Thu, 24 Jan 2002, Oliver Xymoron wrote:

> On Thu, 24 Jan 2002, Richard B. Johnson wrote:
> 
> > On Thu, 24 Jan 2002, Oliver Xymoron wrote:
> >
> > > On Thu, 24 Jan 2002, Jeff Garzik wrote:
> > >
> > > > A small issue...
> > > >
> > > > C99 introduced _Bool as a builtin type.  The gcc patch for it went into
> > > > cvs around Dec 2000.  Any objections to propagating this type and usage
> > > > of 'true' and 'false' around the kernel?
> > >
> > > Ugh, no. C doesn't need booleans, neither do Perl or Python. This is a
> > > sickness imported from _recent_ C++ by way of Java by way of Pascal. This
> > > just complicates things.
> > >
> > > > Where variables are truly boolean use of a bool type makes the
> > > > intentions of the code more clear.  And it also gives the compiler a
> > > > slightly better chance to optimize code [I suspect].
> > >
> > > Unlikely. The compiler can already figure this sort of thing out from
> > > context.
> >
> > IFF the 'C' compiler code-generators start making better code, i.e.,
> > ORing a value already in a register, with itself and jumping on
> > condition, then bool will be helpful. Right now, I see tests against
> > numbers (like 0). This increases the code-size because the 0 is
> > in the instruction stream, plus the comparison of an immediate
> > value to a register value (on Intel) takes more CPU cycles.
> 
> The compiler _will_ turn if(a==0) into a test of a with itself rather than
> a comparison against a constant. Since PDP days, no doubt.


Don't you wish!


int foo(int i)
{

    if(i) return 0;
    else
    return 1;
}

	.file	"xxx.c"
	.version	"01.01"
gcc2_compiled.:
.text
	.align 4
.globl foo
	.type	 foo,@function
foo:
	pushl %ebp
	movl %esp,%ebp
	cmpl $0,8(%ebp)      <-------------- Compare against zero.
	je .L2
	xorl %eax,%eax
	jmp .L1
	jmp .L3
	.align 4
.L2:
	movl $1,%eax
	jmp .L1
	.align 4
.L3:
.L1:
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 foo,.Lfe1-foo
	.ident	"GCC: (GNU) egcs-2.91.66 19990314 (egcs-1.1.2 release)"


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: RFC: booleans and the kernel

[Jeff Garzik]

"Richard B. Johnson" wrote:
> 
> On Thu, 24 Jan 2002, Oliver Xymoron wrote:
> 
> > On Thu, 24 Jan 2002, Richard B. Johnson wrote:
> >
> > > On Thu, 24 Jan 2002, Oliver Xymoron wrote:
> > >
> > > > On Thu, 24 Jan 2002, Jeff Garzik wrote:
> > > >
> > > > > A small issue...
> > > > >
> > > > > C99 introduced _Bool as a builtin type.  The gcc patch for it went into
> > > > > cvs around Dec 2000.  Any objections to propagating this type and usage
> > > > > of 'true' and 'false' around the kernel?
> > > >
> > > > Ugh, no. C doesn't need booleans, neither do Perl or Python. This is a
> > > > sickness imported from _recent_ C++ by way of Java by way of Pascal. This
> > > > just complicates things.
> > > >
> > > > > Where variables are truly boolean use of a bool type makes the
> > > > > intentions of the code more clear.  And it also gives the compiler a
> > > > > slightly better chance to optimize code [I suspect].
> > > >
> > > > Unlikely. The compiler can already figure this sort of thing out from
> > > > context.
> > >
> > > IFF the 'C' compiler code-generators start making better code, i.e.,
> > > ORing a value already in a register, with itself and jumping on
> > > condition, then bool will be helpful. Right now, I see tests against
> > > numbers (like 0). This increases the code-size because the 0 is
> > > in the instruction stream, plus the comparison of an immediate
> > > value to a register value (on Intel) takes more CPU cycles.
> >
> > The compiler _will_ turn if(a==0) into a test of a with itself rather than
> > a comparison against a constant. Since PDP days, no doubt.
> 
> Don't you wish!
> 
> int foo(int i)
> {
> 
>     if(i) return 0;
>     else
>     return 1;
> }

compile with -O2 on a modern compiler :)

        .file   "x.c"
        .text
        .align 16
.globl foo
        .type   foo,@function
foo:
        pushl   %ebp
        movl    %esp, %ebp
        movl    8(%ebp), %eax
        popl    %ebp
        testl   %eax, %eax
        sete    %al
        andl    $255, %eax
        ret
.Lfe1:
        .size   foo,.Lfe1-foo
        .ident  "GCC: (GNU) 3.0.3 (Mandrake Linux 8.2 3.0.3-1mdk)"

-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: RFC: booleans and the kernel

[H. Peter Anvin]

Followup to:  <Pine.LNX.3.95.1020124165419.1859A-100000@chaos.analogic.com>
By author:    "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
> 
> Don't you wish!
> 
> 	cmpl $0,8(%ebp)      <-------------- Compare against zero.

That's the fastest way in x86 to compare a memory variable against
zero.  andl %reg,%reg only works if the value is already in a
register.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: RFC: booleans and the kernel

[Robert Love]

On Thu, 2002-01-24 at 16:55, Richard B. Johnson wrote:

> Don't you wish!
> [snip]
> 	cmpl $0,8(%ebp)      <-------------- Compare against zero.

Ah, but you compiled without optimization.  Using your example program,
`gcc -Wall -S example.c' gives me the same output as you.  But with -O2
I get:

foo:
	pushl	%ebp
	movl	%esp, %ebp
	movl	8(%ebp), %edx
	xorl	%eax, %eax
	testl	%edx, %edx
	sete	%al
	popl	%ebp
	ret

Which is the XOR and self-test with no constant Oliver described.

	Robert Love

Re: RFC: booleans and the kernel

[Timothy Covell]

On Thursday 24 January 2002 14:39, Oliver Xymoron wrote:
>
> The compiler _will_ turn if(a==0) into a test of a with itself rather than
> a comparison against a constant. Since PDP days, no doubt.

I thought that the whole point of booleans was to stop silly errors
like 

if ( x = 1 )
{
	printf ("\nX is true\n");
}
else
{
	# we never get here...
}

-- 
timothy.covell@ashavan.org.

Re: RFC: booleans and the kernel

[Oliver Xymoron]

On Fri, 25 Jan 2002, Timothy Covell wrote:

> On Thursday 24 January 2002 14:39, Oliver Xymoron wrote:
> >
> > The compiler _will_ turn if(a==0) into a test of a with itself rather than
> > a comparison against a constant. Since PDP days, no doubt.
>
> I thought that the whole point of booleans was to stop silly errors
> like
>
> if ( x = 1 )
> {
> 	printf ("\nX is true\n");
> }
> else
> {
> 	# we never get here...
> }

And how does s/1/true/ fix that?

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: RFC: booleans and the kernel

[Timothy Covell]

On Thursday 24 January 2002 15:31, Oliver Xymoron wrote:
> On Fri, 25 Jan 2002, Timothy Covell wrote:
> > On Thursday 24 January 2002 14:39, Oliver Xymoron wrote:
> > > The compiler _will_ turn if(a==0) into a test of a with itself rather
> > > than a comparison against a constant. Since PDP days, no doubt.
> >
> > I thought that the whole point of booleans was to stop silly errors
> > like
> >
> > if ( x = 1 )
> > {
> > 	printf ("\nX is true\n");
> > }
> > else
> > {
> > 	# we never get here...
> > }
>
> And how does s/1/true/ fix that?

It doesn't fix  "if ( x = true)". If would
just make it more legit to use "if (x)".
Just IMHO.

-- 
timothy.covell@ashavan.org.

Re: RFC: booleans and the kernel

[Oliver Xymoron]

On Fri, 25 Jan 2002, Timothy Covell wrote:

> > > I thought that the whole point of booleans was to stop silly errors
> > > like
> > >
> > > if ( x = 1 )
> > > {
> > > 	printf ("\nX is true\n");
> > > }
> > And how does s/1/true/ fix that?
>
> It doesn't fix  "if ( x = true)". If would
> just make it more legit to use "if (x)".

It's been legit and idiomatic since day 1, if not sooner.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: RFC: booleans and the kernel

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.44.0201241545120.2839-100000@waste.org>
By author:    Oliver Xymoron <oxymoron@waste.org>
In newsgroup: linux.dev.kernel
> 
> > It doesn't fix  "if ( x = true)". If would
> > just make it more legit to use "if (x)".
> 
> It's been legit and idiomatic since day 1, if not sooner.
> 

The main reasons for bool is:

a) The ability to save space.  No need to waste a 32- or 64-bit word
   to hold a single bit.  If you're on an architecture that has flags
   or predicates you may be able to carry a boolean in such a value
   instead of in a full register.

b) Compatibility with other languages, including but not limited to
   C++ (there is a standard under development for inter-language linking,
   incidentally.)  C++, of course, needs bool for overloading reasons.

c) The ability to cast to bool and get an unambiguous true or false:

     b = (bool)a;

   This replaces the idiomatic but occationally confusing

     b = !!a;

d) Similarly, you can avoid doing booleanization multiple times:

   /* Highly artificial example */
   int foo(bool a)
   {
       return a ? 55 : 47;
   }

   ... could be implemented by the compiler as 47 + (a << 3), or
   depending on your ABI convention, perhaps a caller calling
   foo(x < 4) could be implemented as foo(x-4) without needing to
   convert it into an integer of exactly 1 and 0.

   Given the way C currently does it, you pretty much have do
   booleanize both in the caller and the callee to be on the safe
   side.

	-hpa


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: RFC: booleans and the kernel

[Werner Almesberger]

H. Peter Anvin wrote:
> c) The ability to cast to bool and get an unambiguous true or false:
> 
>      b = (bool)a;
> 
>    This replaces the idiomatic but occationally confusing
> 
>      b = !!a;

Careful, though. This example

#include <stdbool.h>
#include <stdio.h>

int main(void)
{
    int foo;

    foo = (bool) 4;
    printf("%d\n",foo);
    return 0;
}

e.g. compiled with gcc "2.96" (RH 7.1, 2.96-85), yields 4.

Not sure if this is a flaw of gcc or of the standard. If gcc's
stdbool.h is a standard-compliant implementation of "bool", then
K&Rv2 seems to endorse this behaviour: from A4.2, "Enumerations
behave like integers".

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Lausanne, CH                    wa@almesberger.net /
/_http://icawww.epfl.ch/almesberger/_____________________________________/

Re: RFC: booleans and the kernel

[Jakub Jelinek]

On Fri, Jan 25, 2002 at 04:07:50PM +0100, Werner Almesberger wrote:
> H. Peter Anvin wrote:
> > c) The ability to cast to bool and get an unambiguous true or false:
> > 
> >      b = (bool)a;
> > 
> >    This replaces the idiomatic but occationally confusing
> > 
> >      b = !!a;
> 
> Careful, though. This example
> 
> #include <stdbool.h>
> #include <stdio.h>
> 
> int main(void)
> {
>     int foo;
> 
>     foo = (bool) 4;
>     printf("%d\n",foo);
>     return 0;
> }
> 
> e.g. compiled with gcc "2.96" (RH 7.1, 2.96-85), yields 4.

Yeah, _Bool builtin type was added to gcc 2000-11-13, ie. after 2.96-RH was
branched. It yields 1 in gcc 3.0 or 3.1 CVS though.

	Jakub

Re: RFC: booleans and the kernel

[H. Peter Anvin]

Werner Almesberger wrote:

> 
> Not sure if this is a flaw of gcc or of the standard. If gcc's
> stdbool.h is a standard-compliant implementation of "bool", then
> K&Rv2 seems to endorse this behaviour: from A4.2, "Enumerations
> behave like integers".
> 


This would be a flaw in gcc.

K&Rv2 is C89, so it doesn't apply at all.

	-hpa

Re: RFC: booleans and the kernel

[Robert Love]

On Fri, 2002-01-25 at 16:43, Timothy Covell wrote:

> It doesn't fix  "if ( x = true)". If would
> just make it more legit to use "if (x)".
> Just IMHO.

how is "if (x)" any less legit if x is an integer ?

	Robert Love

Re: RFC: booleans and the kernel

[Timothy Covell]

On Thursday 24 January 2002 16:19, Robert Love wrote:
> On Fri, 2002-01-25 at 16:43, Timothy Covell wrote:
> > It doesn't fix  "if ( x = true)". If would
> > just make it more legit to use "if (x)".
> > Just IMHO.
>
> how is "if (x)" any less legit if x is an integer ?
>
> 	Robert Love
>

What about 

{
    char x;

    if ( x )
    {
        printf ("\n We got here\n");
    }
    else
    {
        // We never get here
        printf ("\n We never got here\n");
    }
}


That's not what I want.   It just seems too open to bugs
and messy IHMO.

-- 
timothy.covell@ashavan.org.

Re: RFC: booleans and the kernel

[Alexander Viro]

On Fri, 25 Jan 2002, Timothy Covell wrote:

> What about 
> 
> {
>     char x;
> 
>     if ( x )
>     {
>         printf ("\n We got here\n");
>     }
>     else
>     {
>         // We never get here
>         printf ("\n We never got here\n");
>     }
> }

What???  Learn the fscking C.

Re: RFC: booleans and the kernel

[Robert Love]

On Fri, 2002-01-25 at 17:30, Timothy Covell wrote:
>
> On Thursday 24 January 2002 16:19, Robert Love wrote:
> > how is "if (x)" any less legit if x is an integer ?
>
> What about 
> 
> {
>     char x;
> 
>     if ( x )
>     {
>         printf ("\n We got here\n");
>     }
>     else
>     {
>         // We never get here
>         printf ("\n We never got here\n");
>     }
> }
> 
> 
> That's not what I want.   It just seems too open to bugs
> and messy IHMO.

When would you ever use the above code?  Your reasoning is "you may
accidentally check a char for a boolean value."  In other words, not
realize it was a char.  What is to say its a boolean?  Or not?  This
isn't an argument.  How does having a boolean type solve this?  Just use
an int.  

	Robert Love

Re: RFC: booleans and the kernel

[Timothy Covell]

On Thursday 24 January 2002 16:38, Robert Love wrote:
> On Fri, 2002-01-25 at 17:30, Timothy Covell wrote:
> > On Thursday 24 January 2002 16:19, Robert Love wrote:
> > > how is "if (x)" any less legit if x is an integer ?
> >
> > What about
> >
> > {
> >     char x;
> >
> >     if ( x )
> >     {
> >         printf ("\n We got here\n");
> >     }
> >     else
> >     {
> >         // We never get here
> >         printf ("\n We never got here\n");
> >     }
> > }
> >
> >
> > That's not what I want.   It just seems too open to bugs
> > and messy IHMO.
>
> When would you ever use the above code?  Your reasoning is "you may
> accidentally check a char for a boolean value."  In other words, not
> realize it was a char.  What is to say its a boolean?  Or not?  This
> isn't an argument.  How does having a boolean type solve this?  Just use
> an int.
>
> 	Robert Love

It would fix this because then the compiler would refuse to compile
"if (x)"  when x is not a bool.    That's what I would call type safety.
But I guess that you all are arguing that C wasn't built that way and
that you don't want it.    

-- 
timothy.covell@ashavan.org.

Re: RFC: booleans and the kernel

[Ragnar Hojland Espinosa]

On Fri, Jan 25, 2002 at 04:44:38PM -0600, Timothy Covell wrote:
> On Thursday 24 January 2002 16:38, Robert Love wrote:
> > On Fri, 2002-01-25 at 17:30, Timothy Covell wrote:
> > > On Thursday 24 January 2002 16:19, Robert Love wrote:
> > > > how is "if (x)" any less legit if x is an integer ?
> > >
> > > What about
> > >
> > > {
> > >     char x;
> > >
> > >     if ( x )
> > >     {
> > >         printf ("\n We got here\n");
> > >     }
> > >     else
> > >     {
> > >         // We never get here
> > >         printf ("\n We never got here\n");
> > >     }
> > > }
> > >
> > >
> > > That's not what I want.   It just seems too open to bugs
> > > and messy IHMO.
> >
> > When would you ever use the above code?  Your reasoning is "you may
> > accidentally check a char for a boolean value."  In other words, not
> > realize it was a char.  What is to say its a boolean?  Or not?  This
> > isn't an argument.  How does having a boolean type solve this?  Just use
> > an int.
> >
> > 	Robert Love
> 
> It would fix this because then the compiler would refuse to compile
> "if (x)"  when x is not a bool.    That's what I would call type safety.
> But I guess that you all are arguing that C wasn't built that way and
> that you don't want it.    

It would actually break this.  if is supposed (and expected) to evaluate
an expression, whatever it will be.  Maybe a gentle warning could be in
place, but refusing to compile is a plain broken C compiler.
-- 
____/|  Ragnar Højland      Freedom - Linux - OpenGL |    Brainbench MVP
\ o.O|  PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
 =(_)=  "Thou shalt not follow the NULL pointer for  | (www.brainbench.com)
   U     chaos and madness await thee at its end."

Re: RFC: booleans and the kernel

[Calin A. Culianu]

On Fri, 25 Jan 2002, Ragnar Hojland Espinosa wrote:

> On Fri, Jan 25, 2002 at 04:44:38PM -0600, Timothy Covell wrote:
> > On Thursday 24 January 2002 16:38, Robert Love wrote:
> > > On Fri, 2002-01-25 at 17:30, Timothy Covell wrote:
> > > > On Thursday 24 January 2002 16:19, Robert Love wrote:
> > > > > how is "if (x)" any less legit if x is an integer ?
> > > >
> > > > What about
> > > >
> > > > {
> > > >     char x;
> > > >
> > > >     if ( x )
> > > >     {
> > > >         printf ("\n We got here\n");
> > > >     }
> > > >     else
> > > >     {
> > > >         // We never get here
> > > >         printf ("\n We never got here\n");
> > > >     }
> > > > }
> > > >
> > > >
> > > > That's not what I want.   It just seems too open to bugs
> > > > and messy IHMO.
> > >
> > > When would you ever use the above code?  Your reasoning is "you may
> > > accidentally check a char for a boolean value."  In other words, not
> > > realize it was a char.  What is to say its a boolean?  Or not?  This
> > > isn't an argument.  How does having a boolean type solve this?  Just use
> > > an int.
> > >
> > > 	Robert Love
> >
> > It would fix this because then the compiler would refuse to compile
> > "if (x)"  when x is not a bool.    That's what I would call type safety.
> > But I guess that you all are arguing that C wasn't built that way and
> > that you don't want it.
>
> It would actually break this.  if is supposed (and expected) to evaluate
> an expression, whatever it will be.  Maybe a gentle warning could be in
> place, but refusing to compile is a plain broken C compiler.
>

I think it is being suggested by whomever the proponent of the bool type
is (I lost track of who wanted it) that maybe keywords that depend on
boolean evaluations (if, while, for, etc.) should only take boolean
expressions as 'parameters', rather than what C does, which is take just
about any expression (everything except automatically allocated structs
being more or less reducible to an int).  This would certainly eliminate
some common typos (typos that any experienced C programmer knows ot look
out for) and make some other code a little more verbose (read: redundant).

So in the strlen example:

int strlen (const char *str)
{
	const char *cur;

	for (cur = str; *cur; cur++);
	return cur - str;
}

It would not be sufficient to check on *cur being true in the for loop,
but you would need an actual boolean expression or boolean type (*cur == 0
or somesuch).

This is a definite change to the C language and while I can see the
benefits of it, I am not sure if it's worth the trouble to alter a
compiler to enforce this type of thing, etc.  :)

-Calin

Re: RFC: booleans and the kernel

[Rick Stevens]

Ragnar Hojland Espinosa wrote:

> On Fri, Jan 25, 2002 at 04:44:38PM -0600, Timothy Covell wrote:
> 
>>On Thursday 24 January 2002 16:38, Robert Love wrote:
>>
>>>On Fri, 2002-01-25 at 17:30, Timothy Covell wrote:
>>>
>>>>On Thursday 24 January 2002 16:19, Robert Love wrote:
>>>>
>>>>>how is "if (x)" any less legit if x is an integer ?
>>>>>
>>>>What about
>>>>
>>>>{
>>>>    char x;
>>>>
>>>>    if ( x )
>>>>    {
>>>>        printf ("\n We got here\n");
>>>>    }
>>>>    else
>>>>    {
>>>>        // We never get here
>>>>        printf ("\n We never got here\n");
>>>>    }
>>>>}
>>>>
>>>>
>>>>That's not what I want.   It just seems too open to bugs
>>>>and messy IHMO.
>>>>
>>>When would you ever use the above code?  Your reasoning is "you may
>>>accidentally check a char for a boolean value."  In other words, not
>>>realize it was a char.  What is to say its a boolean?  Or not?  This
>>>isn't an argument.  How does having a boolean type solve this?  Just use
>>>an int.
>>>
>>>	Robert Love
>>>
>>It would fix this because then the compiler would refuse to compile
>>"if (x)"  when x is not a bool.    That's what I would call type safety.
>>But I guess that you all are arguing that C wasn't built that way and
>>that you don't want it.    
>>
> 
> It would actually break this.  if is supposed (and expected) to evaluate
> an expression, whatever it will be.  Maybe a gentle warning could be in
> place, but refusing to compile is a plain broken C compiler.


Granted.  "if (x)" is true if "x" is non-zero, regardless of type and
shoudn't even generate a warning if "x" is scalar.

Either printf() will occur depending on whether automatics are
initialized to zero or not.  The first one will most likely print
since there's 255 to 1 odds that "x" will be non-zero if not
initialized and I don't think gcc initializes automatics.
----------------------------------------------------------------------
- Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
- 949-743-2010 (Voice)                    http://www.vitalstream.com -
-                                                                    -
-  The problem with being poor is that it takes up all of your time  -
----------------------------------------------------------------------

Re: RFC: booleans and the kernel

[Kai Henningsen]

timothy.covell@ashavan.org (Timothy Covell)  wrote on 25.01.02 in <200201242243.g0OMhAL06878@home.ashavan.org.>:

> On Thursday 24 January 2002 16:38, Robert Love wrote:
> > On Fri, 2002-01-25 at 17:30, Timothy Covell wrote:
> > > On Thursday 24 January 2002 16:19, Robert Love wrote:
> > > > how is "if (x)" any less legit if x is an integer ?
> > >
> > > What about
> > >
> > > {
> > >     char x;
> > >
> > >     if ( x )
> > >     {
> > >         printf ("\n We got here\n");
> > >     }
> > >     else
> > >     {
> > >         // We never get here
> > >         printf ("\n We never got here\n");
> > >     }
> > > }
> > >
> > >
> > > That's not what I want.   It just seems too open to bugs
> > > and messy IHMO.
> >
> > When would you ever use the above code?  Your reasoning is "you may
> > accidentally check a char for a boolean value."  In other words, not
> > realize it was a char.  What is to say its a boolean?  Or not?  This
> > isn't an argument.  How does having a boolean type solve this?  Just use
> > an int.
> >
> > 	Robert Love
>
> It would fix this because then the compiler would refuse to compile
> "if (x)"  when x is not a bool.    That's what I would call type safety.

But that's not what C actually does.

> But I guess that you all are arguing that C wasn't built that way and
> that you don't want it.

We're talking about a specific language feature, and that feature isn't  
what you seem to be thinking it is. It does not change anything you can do  
with ints.


MfG Kai

Re: RFC: booleans and the kernel

[Kai Henningsen]

timothy.covell@ashavan.org (Timothy Covell)  wrote on 26.01.02 in <200201250900.g0P8xoL10082@home.ashavan.org.>:

> On Friday 25 January 2002 00:36, Kai Henningsen wrote:

> > We're talking about a specific language feature, and that feature isn't
> > what you seem to be thinking it is. It does not change anything you can do
> > with ints.
>
> I know, I was talking about typographical errors such as:
>
> int x=0;
>
> if ( x = 1 )
>
>
> or
>
> char x;
> if ( x )
>
> which did not product the desired results.  My thought was to encourage the
> use of booleans instead of ints in these kinds of conditionals.   I thought

And if you changed the int and/or the char into bool, this would  
accomplish exactly nothing. A compiler can warn about assignments in  
conditions or uninitialized variables, and gcc does it already (and has  
done so since a long time); why you think this has anything to do with  
bool seems to be completely unclear to everyone but you.

> admits that there are benefits too.  But, I think it amazing that I'm being
> told that I'm an idiot when even the language's author agrees with me
> on my concerns about C.

Of course, that is again not what is happening. You either *weren't*  
talking about Richie's concerns, or else you were making an excellent  
effort of keeping that fact secret from the rest of us.

What you *were* saying is that you think bool would help get warnings that  
you *already* get and that bool has absolutely no relevance to. I didn't  
exactly call you an idiot for that, but that is certainly the impression  
you left.

MfG Kai

Re: RFC: booleans and the kernel

[Timothy Covell]

On Friday 25 January 2002 13:02, Kai Henningsen wrote:
> timothy.covell@ashavan.org (Timothy Covell)  wrote on 26.01.02 in 
<200201250900.g0P8xoL10082@home.ashavan.org.>:
> > On Friday 25 January 2002 00:36, Kai Henningsen wrote:
> > > We're talking about a specific language feature, and that feature isn't
> > > what you seem to be thinking it is. It does not change anything you can
> > > do with ints.
> >
> > I know, I was talking about typographical errors such as:
> >
> > int x=0;
> >
> > if ( x = 1 )
> >
> >
> > or
> >
> > char x;
> > if ( x )
> >
> > which did not product the desired results.  My thought was to encourage
> > the use of booleans instead of ints in these kinds of conditionals.   I
> > thought
>
> And if you changed the int and/or the char into bool, this would
> accomplish exactly nothing. A compiler can warn about assignments in
> conditions or uninitialized variables, and gcc does it already (and has
> done so since a long time); why you think this has anything to do with
> bool seems to be completely unclear to everyone but you.
>
> > admits that there are benefits too.  But, I think it amazing that I'm
> > being told that I'm an idiot when even the language's author agrees with
> > me on my concerns about C.
>
> Of course, that is again not what is happening. You either *weren't*
> talking about Richie's concerns, or else you were making an excellent
> effort of keeping that fact secret from the rest of us.
>
> What you *were* saying is that you think bool would help get warnings that
> you *already* get and that bool has absolutely no relevance to. I didn't
> exactly call you an idiot for that, but that is certainly the impression
> you left.


You know, I used to wonder why more people didn't like/use Linux.  Now,
after a month or so of reading this website and meeting so many arrogant 
assholes, now I know why.    I think that Tannebaum was right, it's amazing 
that Linus can get such a rag-tag group of "prima donnas" to accomplish 
anything. Of course, it looks like he does it by just looking at the code and 
ignoring the people behind it.

I, on the other hand, do not do that.  I don't use Microsoft because I think 
the company is morally bankrupt.   And now, you and you ilk have convinced 
me to stop lauding Linux.  There are other OSes out there to use, many which 
are both technically and operationally superior and definitely come without
your bad attitude.


----
timothy.covell@ashavan.org.

Re: RFC: booleans and the kernel

[Jamie Lokier]

Timothy Covell wrote:
> You know, I used to wonder why more people didn't like/use Linux.  Now,
> after a month or so of reading this website and meeting so many arrogant 
> assholes, now I know why.

Hey Tim, you wrote a buggy code example that illustrated the wrong
problem, and someone thought you actually meant to indicate that
problem.  Easy mistakes, but you made the first one.

What you call arrogance is simply folk getting to the heart of a
problem, as straightforwardly as feasible.  In this case unfortunately
the wrong one.  I didn't find the other person's words rude at all, but
you did.  Ah, the joy of being different people.

It seems to work for the folk who stay.  If we were all nice and polite,
I daresay many of the engineering-minded folk would get bored and find
somewhere else to insult each other and discuss interesting stuff.

Robust attitude seems to be a requisite for a certain type of
engineering -- it's not pointless: it enables us to ask difficult
questions directly instead of being afraid to.

It's a culture thing, and a working method, is all, and is rarely
intended offensively.

bye,
-- Jamie

Re: RFC: booleans and the kernel

[Kai Henningsen]

lk@tantalophile.demon.co.uk (Jamie Lokier)  wrote on 26.01.02 in <20020126025656.B5730@kushida.apsleyroad.org>:

> Timothy Covell wrote:
> > You know, I used to wonder why more people didn't like/use Linux.  Now,
> > after a month or so of reading this website and meeting so many arrogant
> > assholes, now I know why.
>
> Hey Tim, you wrote a buggy code example that illustrated the wrong
> problem, and someone thought you actually meant to indicate that
> problem.  Easy mistakes, but you made the first one.

Uh, no. Tim *insisted* that he was illustrating the right problem even  
after it was pointed out that he didn't, *and* explained why.

In other words, the guy accusing other people of being arrogant assholes  
is a *dumb* arrogant asshole himself.

> What you call arrogance is simply folk getting to the heart of a
> problem, as straightforwardly as feasible.  In this case unfortunately
> the wrong one.

No. The right ones - both the original and the one Tim raised. *Tim*, of  
course, insisted they were one and the same.

> I didn't find the other person's words rude at all, but
> you did.  Ah, the joy of being different people.

Note that Tim was the one who brought up first the word "idiot", and then  
the "arrogant asshole". All the while accusing us of not being nice  
enough. I smell some double standards here.

Completely predictably, after not getting us to simply swallow his  
arguments without questioning the logic behind them, the next stage is  
"waah, you're all meanies, I'm taking my marbles and am going home".

That is not only no loss, it's good riddance.

> It seems to work for the folk who stay.  If we were all nice and polite,

... people like Tim will still cry how mean we are. Because that is  
exactly what happened.

MfG Kai

Re: RFC: booleans and the kernel

[Nix N. Nix]

On Fri, 2002-01-25 at 06:28, Thomas Hood wrote:
> Jeff Garzik wrote:
> > A small issue...
> 
> ... bound therefore to generate the most discussion ...
> 

:o)

Since we /are/ gorging ourselves in this C-reverie, I might as well:
...
> > int x=0;
> >
> > if ( x = 1 )

In my first-year C programming course, one of my more seasoned (and
phlegmatic) professors recommended that we get used to using 

if (1 == x)

instead of

if (x == 1)

so that, in case we /do/ miss the second '=', creating
(1 = x)
the compiler will puzzle over what exactly we mean by that and ask as
for advice in the form of something like "Error: lvalue required" (or
some such), an error, in any case.



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

Re: RFC: booleans and the kernel

[Xavier Bestel]

le ven 25-01-2002 à 22:24, Timothy Covell a écrit :
> On Thursday 24 January 2002 14:39, Oliver Xymoron wrote:
> >
> > The compiler _will_ turn if(a==0) into a test of a with itself rather than
> > a comparison against a constant. Since PDP days, no doubt.
> 
> I thought that the whole point of booleans was to stop silly errors
> like 
> 
> if ( x = 1 )
> {
> 	printf ("\nX is true\n");
> }
> else
> {
> 	# we never get here...
> }
> 

gcc already warns you about such errors.

	Xav

Re: RFC: booleans and the kernel

[Timothy Covell]

On Thursday 24 January 2002 16:33, Xavier Bestel wrote:
> le ven 25-01-2002 à 22:24, Timothy Covell a écrit :
> > On Thursday 24 January 2002 14:39, Oliver Xymoron wrote:
> > > The compiler _will_ turn if(a==0) into a test of a with itself rather
> > > than a comparison against a constant. Since PDP days, no doubt.
> >
> > I thought that the whole point of booleans was to stop silly errors
> > like
> >
> > if ( x = 1 )
> > {
> > 	printf ("\nX is true\n");
> > }
> > else
> > {
> > 	// we never get here...
> > }
>
> gcc already warns you about such errors.
>
> 	Xav

That's funny, I compiled it with "gcc -Wall foo.c" and got no
warnings.    Please show me what I'm doing wrong and how
it's _my_ mistake and not the compilers.

-- 
timothy.covell@ashavan.org.

Re: RFC: booleans and the kernel

[Xavier Bestel]

le ven 25-01-2002 à 23:47, Timothy Covell a écrit :
> On Thursday 24 January 2002 16:33, Xavier Bestel wrote:
> > le ven 25-01-2002 à 22:24, Timothy Covell a écrit :
> > > On Thursday 24 January 2002 14:39, Oliver Xymoron wrote:
> > > > The compiler _will_ turn if(a==0) into a test of a with itself rather
> > > > than a comparison against a constant. Since PDP days, no doubt.
> > >
> > > I thought that the whole point of booleans was to stop silly errors
> > > like
> > >
> > > if ( x = 1 )
> > > {
> > > 	printf ("\nX is true\n");
> > > }
> > > else
> > > {
> > > 	// we never get here...
> > > }
> >
> > gcc already warns you about such errors.
> >
> > 	Xav
> 
> That's funny, I compiled it with "gcc -Wall foo.c" and got no
> warnings.    Please show me what I'm doing wrong and how
> it's _my_ mistake and not the compilers.

[xav@bip:~]$ gcc -Wall a.c
a.c: In function `main':
a.c:8: warning: suggest parentheses around assignment used as truth value

	Xav

Re: RFC: booleans and the kernel

[Robert Love]

On Fri, 2002-01-25 at 17:47, Timothy Covell wrote:

> > gcc already warns you about such errors.
> >
> > 	Xav
> 
> That's funny, I compiled it with "gcc -Wall foo.c" and got no
> warnings.    Please show me what I'm doing wrong and how
> it's _my_ mistake and not the compilers.

Hm, I recall seeing something like:

warning: suggest parentheses around assignment used as truth value

from gcc ... yep, I still do.

	Robert Love

Re: RFC: booleans and the kernel

[Timothy Covell]

On Thursday 24 January 2002 16:59, Robert Love wrote:
> On Fri, 2002-01-25 at 17:47, Timothy Covell wrote:
> > > gcc already warns you about such errors.
> > >
> > > 	Xav
> >
> > That's funny, I compiled it with "gcc -Wall foo.c" and got no
> > warnings.    Please show me what I'm doing wrong and how
> > it's _my_ mistake and not the compilers.
>
> Hm, I recall seeing something like:
>
> warning: suggest parentheses around assignment used as truth value
>
> from gcc ... yep, I still do.
>
> 	Robert Love
>
My mistake, I was looking at the ouput of my "char x;" example,
which IMHO is even worse.

covell@xxxxxxx ~>cat foo.c

#include <stdio.h>

int main()
{
        char x;

        if ( x )
        {
                printf ("\n We got here\n");
        }
        else
        {
                // We never get here
                printf ("\n We never got here\n");
        }
        exit (0);
}
covell@xxxxxx ~>gcc -Wall foo.c
foo.c: In function `main':
foo.c:17: warning: implicit declaration of function `exit'

-- 
timothy.covell@ashavan.org.

Re: RFC: booleans and the kernel

[Xavier Bestel]

le sam 26-01-2002 à 00:09, Timothy Covell a écrit :
> #include <stdio.h>
> 
> int main()
> {
>         char x;
> 
>         if ( x )
>         {
>                 printf ("\n We got here\n");
>         }
>         else
>         {
>                 // We never get here
>                 printf ("\n We never got here\n");
>         }
>         exit (0);
> }
> covell@xxxxxx ~>gcc -Wall foo.c
> foo.c: In function `main':
> foo.c:17: warning: implicit declaration of function `exit'

I'm lost. What do you want to prove ? (Al Viro would say you just want
to show you don't know C ;)
And why do you think you never get there ?

	Xav

Re: RFC: booleans and the kernel

[Alexander Viro]

On 25 Jan 2002, Xavier Bestel wrote:

> le sam 26-01-2002 Ю 00:09, Timothy Covell a Иcrit :
> > #include <stdio.h>
> > 
> > int main()
> > {
> >         char x;
> > 
> >         if ( x )
> >         {
> >                 printf ("\n We got here\n");
> >         }
> >         else
> >         {
> >                 // We never get here
> >                 printf ("\n We never got here\n");
> >         }
> >         exit (0);
> > }
> > covell@xxxxxx ~>gcc -Wall foo.c
> > foo.c: In function `main':
> > foo.c:17: warning: implicit declaration of function `exit'
> 
> I'm lost. What do you want to prove ? (Al Viro would say you just want
> to show you don't know C ;)
> And why do you think you never get there ?

I suspect that our, ah, Java-loving friend doesn't realize that '\0' is
a legitimate value of type char...

BTW, he's got a funny compiler - I would expect at least a warning about
use of uninitialized variable.

Re: RFC: booleans and the kernel

[Momchil Velikov]

>>>>> "Alexander" == Alexander Viro <viro@math.psu.edu> writes:
>> > int main()
>> > {
>> >         char x;
>> > 
>> >         if ( x )
>> >         {
>> >                 printf ("\n We got here\n");
>> >         }
>> >         else
>> >         {
>> >                 // We never get here
>> >                 printf ("\n We never got here\n");
>> >         }
>> >         exit (0);
>> > }
>> > covell@xxxxxx ~>gcc -Wall foo.c
>> > foo.c: In function `main':
>> > foo.c:17: warning: implicit declaration of function `exit'
>> 
>> I'm lost. What do you want to prove ? (Al Viro would say you just want
>> to show you don't know C ;)
>> And why do you think you never get there ?

Alexander> I suspect that our, ah, Java-loving friend doesn't realize that '\0' is
Alexander> a legitimate value of type char...

Alexander> BTW, he's got a funny compiler - I would expect at least a warning about
Alexander> use of uninitialized variable.

That warning would require data-flow analysis (reachable definitions
in this case), which is not enabled with certain levels of
optimization.

Re: RFC: booleans and the kernel

[Xavier Bestel]

le ven 25-01-2002 à 09:00, Momchil Velikov a écrit :
> >>>>> "Alexander" == Alexander Viro <viro@math.psu.edu> writes:
> >> > int main()
> >> > {
> >> >         char x;
> >> > 
> >> >         if ( x )
> >> >         {
> >> >                 printf ("\n We got here\n");
> >> >         }
> >> >         else
> >> >         {
> >> >                 // We never get here
> >> >                 printf ("\n We never got here\n");
> >> >         }
> >> >         exit (0);
> >> > }
> >> > covell@xxxxxx ~>gcc -Wall foo.c
> >> > foo.c: In function `main':
> >> > foo.c:17: warning: implicit declaration of function `exit'
> >> 
> >> I'm lost. What do you want to prove ? (Al Viro would say you just want
> >> to show you don't know C ;)
> >> And why do you think you never get there ?
> 
> Alexander> I suspect that our, ah, Java-loving friend doesn't realize that '\0' is
> Alexander> a legitimate value of type char...
> 
> Alexander> BTW, he's got a funny compiler - I would expect at least a warning about
> Alexander> use of uninitialized variable.
> 
> That warning would require data-flow analysis (reachable definitions
> in this case), which is not enabled with certain levels of
> optimization.

Yes, the warning is enabled as soon as you start to optimize (-O1 and
more), which is often the case. And if you ask for warnings, of course.

	Xav

Re: RFC: booleans and the kernel

[Olivier Galibert]

On Fri, Jan 25, 2002 at 01:13:21AM -0500, Alexander Viro wrote:
> BTW, he's got a funny compiler - I would expect at least a warning about
> use of uninitialized variable.

That would require -O.  Control path analysis is not done when not
optimizing.

  OG.

Re: RFC: booleans and the kernel

[Timothy Covell]

On Friday 25 January 2002 00:13, Alexander Viro wrote:
> On 25 Jan 2002, Xavier Bestel wrote:
> > le sam 26-01-2002 Ю 00:09, Timothy Covell a Иcrit :
> > > #include <stdio.h>
> > >
> > > int main()
> > > {
> > >         char x;
> > >
> > >         if ( x )
> > >         {
> > >                 printf ("\n We got here\n");
> > >         }
> > >         else
> > >         {
> > >                 // We never get here
> > >                 printf ("\n We never got here\n");
> > >         }
> > >         exit (0);
> > > }
> > > covell@xxxxxx ~>gcc -Wall foo.c
> > > foo.c: In function `main':
> > > foo.c:17: warning: implicit declaration of function `exit'
> >
> > I'm lost. What do you want to prove ? (Al Viro would say you just want
> > to show you don't know C ;)
> > And why do you think you never get there ?
>
> I suspect that our, ah, Java-loving friend doesn't realize that '\0' is
> a legitimate value of type char...
>
> BTW, he's got a funny compiler - I would expect at least a warning about
> use of uninitialized variable.

Java lover's computer gcc -v says:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)



I realize that '\0' is a legit character.   And before you start,
I also realize that a string is a null terminated list of characters (yuck).
My point is to be clean about one's code.    For example, Mark
Hahn sent me a bit of C based strlen code, but I prefer the
Linux kernel implementation which is more explicit and doesn't
make funky implicit nor explicit casts.  Kernel code:
(And, of course, glibc uses Assembly for strlen).


#ifndef __HAVE_ARCH_STRLEN
/**
 * strlen - Find the length of a string
 * @s: The string to be sized
 */
size_t strlen(const char * s)
{
    const char *sc;

    for (sc = s; *sc != '\0'; ++sc)
        /* nothing */;
    return sc - s;
}
#endif


-- 
timothy.covell@ashavan.org.

Re: RFC: booleans and the kernel

[Alexander Viro]

On Sat, 26 Jan 2002, Timothy Covell wrote:

> > > le sam 26-01-2002 Ю 00:09, Timothy Covell a Иcrit :
> > > >         char x;
> > > >
> > > >         if ( x )
> > > >         {
> > > >                 printf ("\n We got here\n");
> > > >         }
> > > >         else
> > > >         {
> > > >                 // We never get here
> > > >                 printf ("\n We never got here\n");
> > > >         }
> > > >         exit (0);

> I realize that '\0' is a legit character.

Then I am at loss - WTF did you mean in the code (and comments) above?

Seriously, learn C.  The fact that you don't understand it is _your_
problem - l-k is not a place to teach you the langauge.

Re: RFC: booleans and the kernel

[J.A. Magallon]

On 20020125 Alexander Viro wrote:
>
>Seriously, learn C.  The fact that you don't understand it is _your_
>problem - l-k is not a place to teach you the langauge.
>

Please, stop with that thing of 'learn C'. C can have bad design points.
It is not perfect. Deal with it, but do not make it a god.

For this special case, what is so bad in halting people to write code
like

a = b + (c>7);

and write it like

a = b + (c>7 ? 1 : 0);

Let the compiler do its work.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.18-pre7-slb #3 SMP Thu Jan 24 02:54:46 CET 2002 i686

Re: RFC: booleans and the kernel

[Kai Henningsen]

jamagallon@able.es (J.A. Magallon)  wrote on 26.01.02 in <20020126004928.A3780@werewolf.able.es>:

> On 20020125 Alexander Viro wrote:
> >
> >Seriously, learn C.  The fact that you don't understand it is _your_
> >problem - l-k is not a place to teach you the langauge.
> >
>
> Please, stop with that thing of 'learn C'. C can have bad design points.
> It is not perfect. Deal with it, but do not make it a god.

He's not making it a god. He's saying that if you wish to discuss its  
design, you first have to learn what that design *is*.

Though personally, I think the problem is less that Tim has problems  
understanding C, but that he couldn't construct a reasonable argument if  
his life depended on it. In this discussion, he's consistently come up  
with code snippets that illustrated different problems than the text he  
wrote to go with them, and then gone all upset when his meaning wasn't  
crystal clear to everyone and everyone didn't applaud him.

MfG Kai

Re: RFC: booleans and the kernel

[John Levon]

On Fri, Jan 25, 2002 at 05:09:45PM -0600, Timothy Covell wrote:

> My mistake, I was looking at the ouput of my "char x;" example,
> which IMHO is even worse.
> 
> covell@xxxxxx ~>gcc -Wall foo.c
> foo.c: In function `main':
> foo.c:17: warning: implicit declaration of function `exit'

and it's still your mistake. Try -O2 as well.

john

-- 
"ALL television is children's television."
	- Richard Adler 

Re: RFC: booleans and the kernel

[Helge Hafting]

Timothy Covell wrote:
> 
> On Thursday 24 January 2002 14:39, Oliver Xymoron wrote:
> >
> > The compiler _will_ turn if(a==0) into a test of a with itself rather than
> > a comparison against a constant. Since PDP days, no doubt.
> 
> I thought that the whole point of booleans was to stop silly errors
> like
> 
> if ( x = 1 )
> {
>         printf ("\nX is true\n");
> }
> else
> {
>         # we never get here...
> }

Booleans won't help that.  If you _want_ to fix that, change
the assignment operator so it don't look like a comparison.
Perhaps x <- 45; or something.  Won't happen to C of course.

Oh, and writing if (a=b) is valid way of testing for a non-zero
b while also assigning to a.  I write code that way when I
need such a set of operation.  Short, elegant, and no, it isn't
hard to read at all.

Helge Hafting

Re: RFC: booleans and the kernel

[Chris Wedgwood]

On Thu, Jan 24, 2002 at 12:42:58PM -0500, Jeff Garzik wrote:

    A small issue...

Which has spawn a bug ugly thread filled with opinions and other stuff
hardly relevant :)

    C99 introduced _Bool as a builtin type.  The gcc patch for it went
    into cvs around Dec 2000.  Any objections to propagating this type
    and usage of 'true' and 'false' around the kernel?

It seems everyone is discussing code efficiency and such like.... How
about we just assume that whether we use if(bool) or if(int) the
compiler produces euqally good and bad code --- I see no evidence to
suggest otherwise.

I don't want to argue over correctness here, too many people already
have.

Surely what is left to discuss was Jeff's original email --- do people
mind the use of this, does it make the source mode readable?

Arguably, I think it does.  It certainly doesn't make it less
readable.



  --cw

Re: RFC: booleans and the kernel

[H. Peter Anvin]

Followup to:  <20020124223325.GA886@tapu.f00f.org>
By author:    Chris Wedgwood <cw@f00f.org>
In newsgroup: linux.dev.kernel
> 
> It seems everyone is discussing code efficiency and such like.... How
> about we just assume that whether we use if(bool) or if(int) the
> compiler produces euqally good and bad code --- I see no evidence to
> suggest otherwise.
> 

Try inserting a compilation unit or other hard optimization boundary.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: RFC: booleans and the kernel

[Chris Wedgwood]

On Thu, Jan 24, 2002 at 02:44:35PM -0800, H. Peter Anvin wrote:

    Try inserting a compilation unit or other hard optimization
    boundary.

Can you provide and example please?

My trivial test comparing "int i, if (i)" verses "bool t, if (t)"
shows the exact same code is produced --- what should I be looking at
here?




  --cw

Re: RFC: booleans and the kernel

[Erik Andersen]

On Thu Jan 24, 2002 at 12:42:58PM -0500, Jeff Garzik wrote:
> A small issue... 
> 
> C99 introduced _Bool as a builtin type.  The gcc patch for it went into
> cvs around Dec 2000.  Any objections to propagating this type and usage
> of 'true' and 'false' around the kernel?
> 
> Where variables are truly boolean use of a bool type makes the
> intentions of the code more clear.  And it also gives the compiler a
> slightly better chance to optimize code [I suspect].
> 
> Actually I prefer 'bool' to '_Bool', if this becomes a kernel standard.

Agreed, bool is nicer.  Out of curiosity, esp 
wrt struct packing, how does gcc actully store 
a bool?  A single bit?  A full 32-bit word?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--