lkml.org 
[lkml]   [2006]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [RFC][PATCH] A generic boolean
    Citerar Alexey Dobriyan <adobriyan@gmail.com>:

    > On Wed, Jul 19, 2006 at 10:38:20PM +0200, ricknu-0@student.ltu.se wrote:
    > > A first step to a generic boolean-type. The patch just introduce the bool
    > (in
    > > arch. i386 only (for the moment)),
    >
    > What's do special about i386?
    Oh, nothing. Meant the patch is only for i386. Because I do not have any other
    setup there were little reason to change for any more arches

    > > -Why would we want it?
    > > -There is already some how are depending on a "boolean"-type (like NTFS).
    > Also,
    > > it will clearify functions who returns a boolean from one returning a
    > value, ex:
    > > bool it_is_ok();
    > > char it_is_ok();
    > > The first one is obvious what it is doing, the secound might return some
    > sort of
    > > status.
    >
    > It should be obvious from name whether function returns int which is a
    > boolean or int which is a number.
    Yes idealy, but sometimes a "obvious" name for someone is a uncertain for others
    + if it is suppose to be an boolean, why not decleare it as one. Have seen quite
    a few: int a; /* boolean */

    > > -Why false and not FALSE, why not "enum {...} bool"
    > > -They are not #define(d) and shouldn't because it is a value, like 'a'.
    > But
    > > because it is just a value, then bool is just a variable and should be able
    > to
    > > handle 0 and 1 equally well.
    >
    > -Why we wouldn't want it
    > -C++ and Java fans will treat bool as a green light to the following
    >
    > if (!(flags == true))
    > and
    > if (!(flags == false))
    Thank god (or someone) for all the C fans who codereview ;)

    Have you actually seen code like that (please point me to the place in that case :)


    > Please, show compiler flag[s] to enable warning[s] from gcc about
    >
    > _Bool foo = 42;
    >
    > Until you do that the whole activity is moot.
    On it...


    > > --- a/include/asm-i386/types.h
    > > +++ b/include/asm-i386/types.h
    > > @@ -10,6 +10,15 @@ typedef unsigned short umode_t;
    > > * header files exported to user space
    > > */
    > >
    > > +#if defined(__GNUC__) && __GNUC__ >= 3
    > > +typedef _Bool bool;
    > > +#else
    > > +#warning You compiler doesn't seem to support boolean types, will set
    > 'bool' as
    > > an 'unsigned char'
    > > +typedef unsigned char bool;
    >
    > Why unsigned char? Why not unsigned int? What would this do wrt
    > bitfields?
    I just took the smallest alternetive to a bit. Many uses an unsigned char as
    boolean, others who uses integer should not suffer either (none of whom I have
    checked).


    > > +#endif
    > > +
    > > +typedef bool u2;
    >
    > What is it?

    Oww, it should be u1 (unsigned 1-bit). Thanks!

    -
    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/
    \
     
     \ /
      Last update: 2006-07-20 00:51    [W:0.044 / U:33.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site