RFC: booleans and the 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.
Jeff
Signature · 3 lines
Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com
Quoted 11 lines · Jeff Garzik
A small issue...
C99 introduced
_Boolas 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
Signature · 5 lines
"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:
Quoted 8 lines
Quoted 1 line · Jeff Garzik
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
Quoted 7 lines
A small issue...
C99 introduced
_Boolas 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?
Quoted 6 lines
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
Signature · 3 lines
<[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:
Quoted 3 lines
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.
Quoted 4 lines
... then use "bool", "true", "false".
This is fine with me as long our version of
stdbool.hcontain the appropriate ifdefs.
- Arnaldo
Quoted 8 lines · Arnaldo Carvalho de Melo
Em Thu, Jan 24, 2002 at 11:28:46AM -0800, H. Peter Anvin escreveu:
Quoted 3 lines
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
Quoted 6 lines · Arnaldo Carvalho de Melo
Em Thu, Jan 24, 2002 at 11:28:46AM -0800, H. Peter Anvin escreveu:
Quoted 3 lines
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
Signature · 3 lines
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/Em Thu, Jan 24, 2002 at 11:43:48AM -0800, H. Peter Anvin escreveu:
Quoted 11 lines
Quoted 5 lines · Arnaldo Carvalho de Melo
Em Thu, Jan 24, 2002 at 11:28:46AM -0800, H. Peter Anvin escreveu:
Quoted 2 lines
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
Quoted 5 lines · Jeff Garzik
A small issue...
C99 introduced
_Boolas 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.
Quoted 3 lines
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.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 7 lines · Oliver Xymoron
Quoted 3 lines · Jeff Garzik
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.
Signature · 3 lines
Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com
Quoted 6 lines · Jeff Garzik
Quoted 5 lines · Oliver Xymoron
Quoted 3 lines · Jeff Garzik
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].
Quoted 6 lines
Quoted 2 lines
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.
Quoted 2 lines
Or a switch statement... if both true and false are covered, there is no need for a 'default'.
Your cases are false and default.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 2 lines · Oliver Xymoron
Because you never test against X==true. You always test X!=false. This is the C way.
That is the theory, yes... :)
Signature · 3 lines
Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com
Quoted 2 lines · Oliver Xymoron
Because you never test against X==true. You always test X!=false. This is the C way.
ITYM "You always test X".
Quoted 6 lines · Alexander Viro
Quoted 2 lines · Oliver Xymoron
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.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 2 lines · Oliver Xymoron
I do indeed, but the bool crowd seems to like making the != explicit for some reason.
that's a ridiculous generalisation.
john
Signature · 2 lines
"ALL television is children's television." - Richard Adler
Quoted 1 line · Jeff Garzik
If one tests X==false and then later on tests X==true,
... one is a wanker. (X == false) is not idiomatic. (!X) is.
Quoted 12 lines · Oliver Xymoron
Quoted 5 lines · Jeff Garzik
A small issue...
C99 introduced
_Boolas 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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 21 lines · Richard B. Johnson
Quoted 12 lines · Oliver Xymoron
Quoted 5 lines · Jeff Garzik
A small issue...
C99 introduced
_Boolas 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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 3 lines · Oliver Xymoron
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...
}Signature · 1 line
[email protected].
Quoted 8 lines · Timothy Covell
Quoted 3 lines · Oliver Xymoron
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
Quoted 8 lines
if ( x = 1 )
{ printf ("\nX is true\n"); } else { # we never get here... }
And how does s/1/true/ fix that?
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 17 lines · Oliver Xymoron
Quoted 7 lines · Timothy Covell
Quoted 2 lines · Oliver Xymoron
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
Quoted 8 lines
if ( x = 1 )
{ printf ("\nX is true\n"); } else { # we never get here... }
Quoted 1 line
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.
Signature · 1 line
[email protected].
Quoted 11 lines · Timothy Covell
Quoted 8 lines
Quoted 7 lines
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.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 3 lines · Timothy Covell
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
Quoted 6 lines
Quoted 3 lines
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
Signature · 3 lines
<[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]>
Quoted 7 lines · H. Peter Anvin
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
Signature · 3 lines
_________________________________________________________________________ / Werner Almesberger, Lausanne, CH [email protected] / /_http://icawww.epfl.ch/almesberger/_____________________________________/
Quoted 23 lines · Werner Almesberger
Quoted 7 lines · H. Peter Anvin
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; }
Quoted 1 line
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
Quoted 6 lines · Werner Almesberger
Not sure if this is a flaw of gcc or of the standard. If gcc's
stdbool.his 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
Quoted 9 lines · Robert Love
Quoted 3 lines · Timothy Covell
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.
Signature · 1 line
[email protected].
Quoted 21 lines · Timothy Covell
Quoted 1 line · Robert Love
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"); } }
Quoted 2 lines
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
Quoted 15 lines · Timothy Covell
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.
Quoted 24 lines · Robert Love
Quoted 20 lines · Timothy Covell
Quoted 1 line · Robert Love
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"); } }Quoted 2 lines
That's not what I want. It just seems too open to bugs
and messy IHMO.
Quoted 7 lines
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.
Signature · 1 line
[email protected].
[email protected] (Timothy Covell) wrote on 25.01.02 in <[email protected].>:
Quoted 31 lines · Robert Love
Quoted 30 lines · Timothy Covell
Quoted 20 lines · Robert Love
Quoted 1 line
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"); } }Quoted 2 lines
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.
Quoted 4 lines
Quoted 1 line
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.
Quoted 2 lines
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
Quoted 1 line · Kai Henningsen
[email protected] (Timothy Covell) wrote on 26.01.02 in
Quoted 31 lines
Quoted 12 lines · Kai Henningsen
Quoted 3 lines
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 )
Quoted 8 lines
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
thoughtAnd 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.
Quoted 3 lines
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.
Quoted 8 lines
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].
Quoted 3 lines · Timothy Covell
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
[email protected] (Jamie Lokier) wrote on 26.01.02 in <[email protected]>:
Quoted 8 lines
Quoted 3 lines · Timothy Covell
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 1 line
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
Quoted 31 lines · Timothy Covell
Quoted 30 lines · Robert Love
Quoted 20 lines · Timothy Covell
Quoted 1 line · Robert Love
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"); } }Quoted 2 lines
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.
Quoted 6 lines
Quoted 1 line
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.
Signature · 4 lines
____/| 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."
Quoted 34 lines · Ragnar Hojland Espinosa
Quoted 33 lines · Timothy Covell
Quoted 31 lines · Robert Love
Quoted 20 lines · Timothy Covell
Quoted 1 line · Robert Love
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"); } }Quoted 2 lines
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
Quoted 9 lines
Quoted 4 lines
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
Quoted 44 lines · Ragnar Hojland Espinosa
Quoted 34 lines · Timothy Covell
Quoted 32 lines · Robert Love
Quoted 21 lines · Timothy Covell
Quoted 2 lines · Robert Love
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"); } }Quoted 3 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 3 lines
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 -
----------------------------------------------------------------------
Quoted 8 lines · Timothy Covell
Quoted 3 lines · Oliver Xymoron
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
Quoted 9 lines
if ( x = 1 )
{ printf ("\nX is true\n"); } else { # we never get here... }
gcc already warns you about such errors.
Xav
Quoted 30 lines · Oliver Xymoron
Quoted 21 lines · Richard B. Johnson
Quoted 12 lines · Oliver Xymoron
Quoted 5 lines · Jeff Garzik
A small issue...
C99 introduced
_Boolas 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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
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.
Quoted 38 lines · Richard B. Johnson
Quoted 30 lines · Oliver Xymoron
Quoted 21 lines · Richard B. Johnson
Quoted 12 lines · Oliver Xymoron
Quoted 5 lines · Jeff Garzik
A small issue...
C99 introduced
_Boolas 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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
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!
Quoted 7 lines
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)"Signature · 3 lines
Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com
Quoted 3 lines · Richard B. Johnson
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
Followup to: <[email protected]> By author: "Richard B. Johnson" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 4 lines
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
Signature · 3 lines
<[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]>
Quoted 17 lines · Xavier Bestel
Quoted 7 lines · Timothy Covell
Quoted 2 lines · Oliver Xymoron
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
Quoted 8 lines
if ( x = 1 )
{ printf ("\nX is true\n"); } else { // we never get here... }
Quoted 3 lines
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.
Signature · 1 line
[email protected].
Quoted 18 lines · Timothy Covell
Quoted 17 lines · Xavier Bestel
Quoted 15 lines · Timothy Covell
Quoted 2 lines · Oliver Xymoron
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... }
Quoted 7 lines
Quoted 3 lines
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
Quoted 7 lines · Timothy Covell
Quoted 3 lines
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
Quoted 9 lines · Robert Love
Quoted 7 lines · Timothy Covell
Quoted 3 lines
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.
Quoted 8 lines
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.cfoo.c: In function `main':
foo.c:17: warning: implicit declaration of function `exit'
Signature · 1 line
[email protected].
Quoted 17 lines · Timothy Covell
#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); }
Quoted 3 lines
covell@xxxxxx ~>gcc -Wall
foo.cfoo.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
Quoted 22 lines · Xavier Bestel
le sam 26-01-2002 Ю 00:09, Timothy Covell a Иcrit :
Quoted 17 lines
#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); }Quoted 3 lines
covell@xxxxxx ~>gcc -Wall
foo.cfoo.c: In function `main':
foo.c:17: warning: implicit declaration of function `exit'
Quoted 3 lines
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.
Quoted 27 lines · Alexander Viro
Quoted 22 lines · Xavier Bestel
le sam 26-01-2002 Ю 00:09, Timothy Covell a Иcrit :
Quoted 17 lines
#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); }Quoted 3 lines
covell@xxxxxx ~>gcc -Wall
foo.cfoo.c: In function `main':
foo.c:17: warning: implicit declaration of function `exit'Quoted 3 lines
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 ?
Quoted 5 lines
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
Signature · 1 line
[email protected].
Quoted 14 lines · Timothy Covell
Quoted 13 lines
Quoted 13 lines
le sam 26-01-2002 Ю 00:09, Timothy Covell a Иcrit :
Quoted 12 lines
char x; if ( x ) { printf ("\n We got here\n"); } else { // We never get here printf ("\n We never got here\n"); } exit (0);
Quoted 1 line
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.
Quoted 4 lines · 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.
Signature · 4 lines
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] (J.A. Magallon) wrote on 26.01.02 in <[email protected]>:
Quoted 8 lines · On 20020125 Alexander Viro wrote:
Quoted 4 lines
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
Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
Quoted 1 line
Quoted 1 line
"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.cfoo.c: In function `main':
foo.c:17: warning: implicit declaration of function `exit'
Quoted 3 lines
Quoted 3 lines
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.
Quoted 27 lines · Momchil Velikov
Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
Quoted 1 line
Quoted 1 line
"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.cfoo.c: In function `main':
foo.c:17: warning: implicit declaration of function `exit'Quoted 3 lines
Quoted 3 lines
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...
Quoted 6 lines
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
Quoted 2 lines · Alexander Viro
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.
Quoted 6 lines · Timothy Covell
My mistake, I was looking at the ouput of my "char x;" example, which IMHO is even worse.
covell@xxxxxx ~>gcc -Wall
foo.cfoo.c: In function `main':
foo.c:17: warning: implicit declaration of function `exit'
and it's still your mistake. Try -O2 as well.
john
Signature · 2 lines
"ALL television is children's television." - Richard Adler
Quoted 9 lines · Timothy Covell
Quoted 3 lines · Oliver Xymoron
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
Quoted 8 lines
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
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
Followup to: <[email protected]> By author: Chris Wedgwood <[email protected]> In newsgroup: linux.dev.kernel
Quoted 6 lines
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
Signature · 3 lines
<[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]>
Quoted 11 lines · Jeff Garzik
A small issue...
C99 introduced
_Boolas 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 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