Messages in this thread | | | Date | Fri, 25 Jan 2002 04:52:06 +0100 | From | Ragnar Hojland Espinosa <> | Subject | Re: RFC: booleans and the kernel |
| |
On Fri, Jan 25, 2002 at 04:44:38PM -0600, Timothy Covell wrote: > On Thursday 24 January 2002 16:38, Robert Love wrote: > > On Fri, 2002-01-25 at 17:30, Timothy Covell wrote: > > > On Thursday 24 January 2002 16:19, Robert Love wrote: > > > > how is "if (x)" any less legit if x is an integer ? > > > > > > What about > > > > > > { > > > char x; > > > > > > if ( x ) > > > { > > > printf ("\n We got here\n"); > > > } > > > else > > > { > > > // We never get here > > > printf ("\n We never got here\n"); > > > } > > > } > > > > > > > > > That's not what I want. It just seems too open to bugs > > > and messy IHMO. > > > > When would you ever use the above code? Your reasoning is "you may > > accidentally check a char for a boolean value." In other words, not > > realize it was a char. What is to say its a boolean? Or not? This > > isn't an argument. How does having a boolean type solve this? Just use > > an int. > > > > Robert Love > > It would fix this because then the compiler would refuse to compile > "if (x)" when x is not a bool. That's what I would call type safety. > But I guess that you all are arguing that C wasn't built that way and > that you don't want it.
It would actually break this. if is supposed (and expected) to evaluate an expression, whatever it will be. Maybe a gentle warning could be in place, but refusing to compile is a plain broken C compiler. -- ____/| Ragnar Højland Freedom - Linux - OpenGL | Brainbench MVP \ o.O| PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming =(_)= "Thou shalt not follow the NULL pointer for | (www.brainbench.com) U chaos and madness await thee at its end." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |