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
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/
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
Followup to: <[email protected]>
By author: Jeff Garzik <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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
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
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
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/
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.."
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
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.."
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
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.
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.
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".
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.."
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
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.."
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...
}
--
[email protected].
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.."
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.
--
[email protected].
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.."
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.
"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
Followup to: <[email protected]>
By author: "Richard B. Johnson" <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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
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
Followup to: <[email protected]>
By author: Oliver Xymoron <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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.
--
[email protected].
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
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
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
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.
Followup to: <[email protected]>
By author: Chris Wedgwood <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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.
--
[email protected].
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.
--
[email protected].
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
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
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'
--
[email protected].
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
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
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--
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.
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
--
[email protected].
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 | (http://www.brainbench.com)
U chaos and madness await thee at its end."
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.
>>>>> "Alexander" == Alexander Viro <[email protected]> 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.
[email protected] (Timothy Covell) wrote on 25.01.02 in <[email protected].>:
> 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
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
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
le ven 25-01-2002 ? 09:00, Momchil Velikov a ?crit :
> >>>>> "Alexander" == Alexander Viro <[email protected]> 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
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
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
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 [email protected] /
/_http://icawww.epfl.ch/almesberger/_____________________________________/
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
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.
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
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
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. [email protected] -
- 949-743-2010 (Voice) http://www.vitalstream.com -
- -
- The problem with being poor is that it takes up all of your time -
----------------------------------------------------------------------
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:[email protected]
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
[email protected] (Timothy Covell) wrote on 26.01.02 in <[email protected].>:
> 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
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
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
On Friday 25 January 2002 13:02, Kai Henningsen wrote:
> [email protected] (Timothy Covell) wrote on 26.01.02 in
<[email protected].>:
> > 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.
----
[email protected].
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
[email protected]
[email protected]
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--
(http://www.geekcode.com)
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
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
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.
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
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
[email protected] (J.A. Magallon) wrote on 26.01.02 in <[email protected]>:
> 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
[email protected] (Jamie Lokier) wrote on 26.01.02 in <[email protected]>:
> 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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>