Re: [patch 1/1] consolidate TRUE and FALSE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 16 Mar 2006, Anton Altaparmakov wrote:

> On Thu, 16 Mar 2006, Al Viro wrote:
> > On Thu, Mar 16, 2006 at 04:42:29PM +0000, Anton Altaparmakov wrote:
> > > Again, in your opinion.  To me it is a simple consequence of there not 
> > > being a boolean type in the kernel so you cannot use it in the core code.  
> > > Once there is such a type I would imagine users will appear in the core 
> > > code over time.
> > 
> > And that's supposed to be an argument in favour of that crap?
> 
> No, it was an alternative interpretation to Christoph's statement that the 
> non-use of booleans was due to them being crap.  So I said that you can't 
> use what you don't have and I imagine the majority of people do not want 
> these pointless flamewars so no-one has so far bothered to introduce a 
> generic bollean type in the kernel...
> 
> Andy why is it crap?  For a start it is valid C (well, ok C99, but even 

s/Andy/And/...

> you are fond of a lot of C99 features like the initializers) and second 
> it makes code more readable and makes meaning of functions a lot more 
> obvious, e.g reading:
> 
> "extern bool foo_is_compressed(bar);"
> 
> in a header file makes it damn obvious that if foo_is_compressed() returns 
> "true" then "bar" is compressed and if it returns "false" then "bar" is 
> not compressed.
> 
> If you see:
> 
> "extern int foo_is_compressed(bar);"
> 
> You have to go find the .c file containing the function and read it to 
> figure out what the heck the return value means/is.  And don't tell me you 
> can rely on it returning 0 for not-compressed and 1 for compressed.  For a 
> start it could return < 0 for error and a myriad of other things.  
> Especially in the kernel core the functions like that seem to randomly 
> return 0 for true and 1 for false and worse.  But even if they were 
> consistent you could never rule out the < 0 for error case unless you read 
> the function itself.
> 
> So I beg to differ with your opinion of boolean type being crap.
> 
> As you might have noticed already, I think booleans have their place and 
> make code much more readable when used appropriately.  I have only been 
> programming for the last 24 years and I like booleans and no-one is going 
> to get me to think otherwise after such a long time...
> 
> I am happy to agree that we disagree.  Just stay away with s/true/1/ 
> and s/false/0/ conversions from fs/ntfs/ please and I will shut up...  (-:
> 
> Best regards,
> 
> 	Anton
> 

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux