[KJ] standardizing on boolean variables?

[KJ] standardizing on boolean variables?

[Robert P. J. Day]

  how hard would it be to define a standard for a simple true/false
boolean variable for the kernel?  gcc has had support for the C99
"_Bool" type for years, and additionally defines, in
include/linux/types.h:

  typedef _Bool                   bool;

so there's no reason to not use "bool" anywhere you need an actual
boolean, is there?

  however, it seems everyone wants to define their own macros for
the actual values "true" and "false":

  $ grep -r "define TRUE" .
  $ grep -r "define FALSE" .

yeesh.  would there be a problem adding those two defines to
"types.h", then deleting all those additional macro definitions?

  one might also get rid of redundant typedefs like:

  $ grep -r "typedef.*bool" .

where people insist on re-inventing their own booleans types.

rday

p.s.  the source file drivers/scsi/BusLogic.c repeatedly refers to the
token "true", but it's not clear where *that's" being defined.  goes
gcc actually recognize the token "true"?  that's supposed to be
defined in C99's <stdbool.h>, but that's clearly not being used here.
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Alexey Dobriyan]

On Sun, Jan 21, 2007 at 03:36:33AM -0500, Robert P. J. Day wrote:
> p.s.  the source file drivers/scsi/BusLogic.c repeatedly refers to the
> token "true", but it's not clear where *that's" being defined.  goes
> gcc actually recognize the token "true"?  that's supposed to be
> defined in C99's <stdbool.h>, but that's clearly not being used here.

When in doubt see preprocessor output:

	make drivers/scsi/BusLogic.i

	# 1 "/home/linux/linux-irq-flags-t/include/linux/stddef.h" 1
	# 15 "/home/linux/linux-irq-flags-t/include/linux/stddef.h"
	enum {
	 false = 0,
	 true = 1
	};

Indeed, "true" is right there.

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Robert P. J. Day]

On Sun, 21 Jan 2007, Alexey Dobriyan wrote:

> On Sun, Jan 21, 2007 at 03:36:33AM -0500, Robert P. J. Day wrote:
> > p.s.  the source file drivers/scsi/BusLogic.c repeatedly refers to the
> > token "true", but it's not clear where *that's" being defined.  goes
> > gcc actually recognize the token "true"?  that's supposed to be
> > defined in C99's <stdbool.h>, but that's clearly not being used here.
>
> When in doubt see preprocessor output:
>
> 	make drivers/scsi/BusLogic.i
>
> 	# 1 "/home/linux/linux-irq-flags-t/include/linux/stddef.h" 1
> 	# 15 "/home/linux/linux-irq-flags-t/include/linux/stddef.h"
> 	enum {
> 	 false = 0,
> 	 true = 1
> 	};
>
> Indeed, "true" is right there.

ah, quite right, i missed that.  but that, of course, just raises
another question -- why have two different sets of tokens representing
boolean values?  should programmers use the upper or lower case form?
and why did the person who wrote BusLogic.c do it differently from
everyone else?  so many pedantic, anal-retentive questions.

but back to the question at hand -- is there any fundamental problem
with trying to define a standard by defining TRUE and FALSE macros in
types.h?  certainly, that would also require some simultaneous fixes
to the source tree, where those new macros would clash with existing
code, like in drivers/net/wireless/strip.c, where one would have to
remove the conflicting:

  enum { FALSE = 0, TRUE = 1 };

but i'm guessing things like that would be rare.

rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Tobias Klauser]

On 2007-01-21 at 09:36:33 +0100, Robert P. J. Day <rpjday@mindspring.com> wrote:
>   how hard would it be to define a standard for a simple true/false
> boolean variable for the kernel?  gcc has had support for the C99
> "_Bool" type for years, and additionally defines, in
> include/linux/types.h:
> 
>   typedef _Bool                   bool;
> 
> so there's no reason to not use "bool" anywhere you need an actual
> boolean, is there?
> 
>   however, it seems everyone wants to define their own macros for
> the actual values "true" and "false":
> 
>   $ grep -r "define TRUE" .
>   $ grep -r "define FALSE" .
> 
> yeesh.  would there be a problem adding those two defines to
> "types.h", then deleting all those additional macro definitions?
> 
>   one might also get rid of redundant typedefs like:
> 
>   $ grep -r "typedef.*bool" .
> 
> where people insist on re-inventing their own booleans types.

There was an effort by Andrew Morton [1] to clean this up some time ago.
AFAIR the patch wasn't accepted but I don't remember the exact reason.

[1] http://marc2.theaimsgroup.com/?l=linux-kernel&m\x114250357613993&w=2

Cheers,
Tobias
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Richard Knutsson]

Robert P. J. Day wrote:
> On Sun, 21 Jan 2007, Alexey Dobriyan wrote:
>
>   
>> On Sun, Jan 21, 2007 at 03:36:33AM -0500, Robert P. J. Day wrote:
>>     
>>> p.s.  the source file drivers/scsi/BusLogic.c repeatedly refers to the
>>> token "true", but it's not clear where *that's" being defined.  goes
>>> gcc actually recognize the token "true"?  that's supposed to be
>>> defined in C99's <stdbool.h>, but that's clearly not being used here.
>>>       
>> When in doubt see preprocessor output:
>>
>> 	make drivers/scsi/BusLogic.i
>>
>> 	# 1 "/home/linux/linux-irq-flags-t/include/linux/stddef.h" 1
>> 	# 15 "/home/linux/linux-irq-flags-t/include/linux/stddef.h"
>> 	enum {
>> 	 false = 0,
>> 	 true = 1
>> 	};
>>
>> Indeed, "true" is right there.
>>     
>
> ah, quite right, i missed that.  but that, of course, just raises
> another question -- why have two different sets of tokens representing
> boolean values?  should programmers use the upper or lower case form?
> and why did the person who wrote BusLogic.c do it differently from
> everyone else?  so many pedantic, anal-retentive questions.
>   
Simple, some people defines 'FALSE'/'TRUE' and some 'false'/'true' ;)
Then, to be able to compile, the 
"6e21828743247270d09a86756a0c11702500dbfb" (git show) redefined BusLogic.h's

-typedef enum { false, true } __attribute__ ((packed)) boolean;

to

+typedef bool boolean;

Also, NTFS has been converted and some more filesystems.
> but back to the question at hand -- is there any fundamental problem
> with trying to define a standard by defining TRUE and FALSE macros in
> types.h?  certainly, that would also require some simultaneous fixes
> to the source tree, where those new macros would clash with existing
> code, like in drivers/net/wireless/strip.c, where one would have to
> remove the conflicting:
>
>   enum { FALSE = 0, TRUE = 1 };
>
> but i'm guessing things like that would be rare.
>   
Please, try to convert it to 'false'/'true' instead. It is meant to be 
the generic boolean-values, same as bool being the type.
Believe it is approved since I saw a patch, adding a function using bool 
and 'false'/'true', signed-off-by Torvalds and Morton (not sure it was a 
third name).

I have not got too much done in the converting-front (some wants it 
changed to int/0/1 instead); maybe this is something to add on Wiki- ToDo :)

Richard Knutsson

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Robert P. J. Day]

On Sun, 21 Jan 2007, Tobias Klauser wrote:

> There was an effort by Andrew Morton [1] to clean this up some time
> ago. AFAIR the patch wasn't accepted but I don't remember the exact
> reason.
>
> [1] http://marc2.theaimsgroup.com/?l=linux-kernel&m\x114250357613993&w=2

sigh.  i just finished reading that thread -- many ostensibly
intelligent people waxing philosophical and, in the end, doing sweet
FA.  this is starting to get depressingly familiar.

rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Robert P. J. Day]

On Sun, 21 Jan 2007, Richard Knutsson wrote:

> Robert P. J. Day wrote:

> > ah, quite right, i missed that.  but that, of course, just raises
> > another question -- why have two different sets of tokens
> > representing boolean values?  should programmers use the upper or
> > lower case form? and why did the person who wrote BusLogic.c do it
> > differently from everyone else?  so many pedantic, anal-retentive
> > questions.
> >
> Simple, some people defines 'FALSE'/'TRUE' and some 'false'/'true' ;)

actually, while lots of files define 'FALSE' and 'TRUE', very few
files define values for the tokens 'false' and 'true' since, as alexey
pointed out, those are defined in include/linux/stddef.h:

enum {
        false   = 0,
        true    = 1
};


> Then, to be able to compile, the
> "6e21828743247270d09a86756a0c11702500dbfb" (git show) redefined
> BusLogic.h's
>
> -typedef enum { false, true } __attribute__ ((packed)) boolean;
>
> to
>
> +typedef bool boolean;

but that second typedef doesn't define any values for the tokens
'true' and 'false', so that still has to be done by *someone*.

> > but back to the question at hand -- is there any fundamental
> > problem with trying to define a standard by defining TRUE and
> > FALSE macros in types.h?  certainly, that would also require some
> > simultaneous fixes to the source tree, where those new macros
> > would clash with existing code, like in
> > drivers/net/wireless/strip.c, where one would have to remove the
> > conflicting:
> >
> >   enum { FALSE = 0, TRUE = 1 };
> >
> > but i'm guessing things like that would be rare.
> >
> Please, try to convert it to 'false'/'true' instead. It is meant to
> be the generic boolean-values, same as bool being the type.
>
> Believe it is approved since I saw a patch, adding a function using bool and
> 'false'/'true', signed-off-by Torvalds and Morton (not sure it was a third
> name).

i just read that thread, and it consisted of lots of smart people
arguing over how many angels could fit on the head of a pin, then
finally losing interesting and wandering away, having accomplished
absolutely nothing.

i just submitted the following patch to LKML:

===========================
diff --git a/drivers/net/wireless/strip.c
b/drivers/net/wireless/strip.c
index ce3a8ba..5e64ec1 100644
--- a/drivers/net/wireless/strip.c
+++ b/drivers/net/wireless/strip.c
@@ -177,8 +177,6 @@ typedef struct {
        MetricomNode node[NODE_TABLE_SIZE];
 } MetricomNodeTable;

-enum { FALSE = 0, TRUE = 1 };
-
 /*
  * Holds the radio's firmware version.
  */
diff --git a/include/linux/types.h b/include/linux/types.h
index 0351bf2..d988636 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -34,6 +34,8 @@ typedef __kernel_mqd_t                mqd_t;

 #ifdef __KERNEL__
 typedef _Bool                  bool;
+#define TRUE                   1
+#define FALSE                  0

 typedef __kernel_uid32_t       uid_t;
 typedef __kernel_gid32_t       gid_t;
===============================

  note that it adds definitions for TRUE and FALSE to types.h (and
removes a single conflicting construct), so that all of those
ridiculous macro definitions can be removed from the numerous source
files.  note also that it doesn't take a position on what tokens to
use in the future, it just allows for *removal* of lots of unnecessary
crap.  so applying that patch doesn't require finalizing a decision on
what should be done in the future, although i'm sure that's the
argument i'm going to hear.  wait for it -- you know it's coming.

> I have not got too much done in the converting-front (some wants it
> changed to int/0/1 instead); maybe this is something to add on Wiki-
> ToDo :)

  as soon as the wiki exists, we can get started.

rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Richard Knutsson]

Robert P. J. Day wrote:
> On Sun, 21 Jan 2007, Richard Knutsson wrote:
>
>   
>> Robert P. J. Day wrote:
>>     
>
>   
>>> ah, quite right, i missed that.  but that, of course, just raises
>>> another question -- why have two different sets of tokens
>>> representing boolean values?  should programmers use the upper or
>>> lower case form? and why did the person who wrote BusLogic.c do it
>>> differently from everyone else?  so many pedantic, anal-retentive
>>> questions.
>>>
>>>       
>> Simple, some people defines 'FALSE'/'TRUE' and some 'false'/'true' ;)
>>     
>
> actually, while lots of files define 'FALSE' and 'TRUE', very few
> files define values for the tokens 'false' and 'true' since, as alexey
> pointed out, those are defined in include/linux/stddef.h:
>
> enum {
>         false   = 0,
>         true    = 1
> };
>
>   
No file should define 'false' and 'true' since I removed them to make it 
build with the above. Please point me to those if you find any.
>> Then, to be able to compile, the
>> "6e21828743247270d09a86756a0c11702500dbfb" (git show) redefined
>> BusLogic.h's
>>
>> -typedef enum { false, true } __attribute__ ((packed)) boolean;
>>
>> to
>>
>> +typedef bool boolean;
>>     
>
> but that second typedef doesn't define any values for the tokens
> 'true' and 'false', so that still has to be done by *someone*.
>   
That was a quick-fix to get rid of the defining of 'false'/'true'. So 
now a find 'n' replace of 'boolean' should be painless (can submit a 
patch later today...)
>>> but back to the question at hand -- is there any fundamental
>>> problem with trying to define a standard by defining TRUE and
>>> FALSE macros in types.h?  certainly, that would also require some
>>> simultaneous fixes to the source tree, where those new macros
>>> would clash with existing code, like in
>>> drivers/net/wireless/strip.c, where one would have to remove the
>>> conflicting:
>>>
>>>   enum { FALSE = 0, TRUE = 1 };
>>>
>>> but i'm guessing things like that would be rare.
>>>
>>>       
>> Please, try to convert it to 'false'/'true' instead. It is meant to
>> be the generic boolean-values, same as bool being the type.
>>
>> Believe it is approved since I saw a patch, adding a function using bool and
>> 'false'/'true', signed-off-by Torvalds and Morton (not sure it was a third
>> name).
>>     
>
> i just read that thread, and it consisted of lots of smart people
> arguing over how many angels could fit on the head of a pin, then
> finally losing interesting and wandering away, having accomplished
> absolutely nothing.
>   
Guess you referring to Andrew Morton's "[patch 1/1] consolidate TRUE and 
FALSE".
> i just submitted the following patch to LKML:
>
> ===========================
> diff --git a/drivers/net/wireless/strip.c
> b/drivers/net/wireless/strip.c
> index ce3a8ba..5e64ec1 100644
> --- a/drivers/net/wireless/strip.c
> +++ b/drivers/net/wireless/strip.c
> @@ -177,8 +177,6 @@ typedef struct {
>         MetricomNode node[NODE_TABLE_SIZE];
>  } MetricomNodeTable;
>
> -enum { FALSE = 0, TRUE = 1 };
> -
>  /*
>   * Holds the radio's firmware version.
>   */
>   
Have you done a "allyes"-build? Surprised there is not more to do...
> diff --git a/include/linux/types.h b/include/linux/types.h
> index 0351bf2..d988636 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -34,6 +34,8 @@ typedef __kernel_mqd_t                mqd_t;
>
>  #ifdef __KERNEL__
>  typedef _Bool                  bool;
> +#define TRUE                   1
> +#define FALSE                  0
>   
First of, I believe this should be in stddef.h (as 'false'/'true'/NULL).
Second, why add a second definition of false and true? I have yet to 
hear someone wanting upper-cast instead of lower (0/1 yes, but not 
upper-cast).
Actually some would like it to be 'null' instead of NULL :)
>  typedef __kernel_uid32_t       uid_t;
>  typedef __kernel_gid32_t       gid_t;
> ===============================
>
>   note that it adds definitions for TRUE and FALSE to types.h (and
> removes a single conflicting construct), so that all of those
> ridiculous macro definitions can be removed from the numerous source
> files.  note also that it doesn't take a position on what tokens to
> use in the future, it just allows for *removal* of lots of unnecessary
> crap.  so applying that patch doesn't require finalizing a decision on
> what should be done in the future, although i'm sure that's the
> argument i'm going to hear.  wait for it -- you know it's coming.
>   
Just, what is the rush to remove that "crap"? It's been there for quite 
some time and will be taken care of when converted to a generic boolean.

Richard Knutsson
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Robert P. J. Day]

On Sun, 21 Jan 2007, Richard Knutsson wrote:

> Robert P. J. Day wrote:

> > actually, while lots of files define 'FALSE' and 'TRUE', very few
> > files define values for the tokens 'false' and 'true' since, as alexey
> > pointed out, those are defined in include/linux/stddef.h:
> >
> > enum {
> >         false   = 0,
> >         true    = 1
> > };
> >
> >

> No file should define 'false' and 'true' since I removed them to
> make it build with the above. Please point me to those if you find
> any.

sorry, bad phrasing on my part.  there are no others.

> > > Then, to be able to compile, the
> > > "6e21828743247270d09a86756a0c11702500dbfb" (git show) redefined
> > > BusLogic.h's
> > >
> > > -typedef enum { false, true } __attribute__ ((packed)) boolean;
> > >
> > > to
> > >
> > > +typedef bool boolean;
> > >
> >
> > but that second typedef doesn't define any values for the tokens
> > 'true' and 'false', so that still has to be done by *someone*.
> >
> That was a quick-fix to get rid of the defining of 'false'/'true'.
> So now a find 'n' replace of 'boolean' should be painless (can
> submit a patch later today...)

ok, that makes sense.

> > i just submitted the following patch to LKML:
> >
> > ===========================
> > diff --git a/drivers/net/wireless/strip.c
> > b/drivers/net/wireless/strip.c
> > index ce3a8ba..5e64ec1 100644
> > --- a/drivers/net/wireless/strip.c
> > +++ b/drivers/net/wireless/strip.c
> > @@ -177,8 +177,6 @@ typedef struct {
> >         MetricomNode node[NODE_TABLE_SIZE];
> >  } MetricomNodeTable;
> >
> > -enum { FALSE = 0, TRUE = 1 };
> > -
> >  /*
> >   * Holds the radio's firmware version.
> >   */
> >
> Have you done a "allyes"-build? Surprised there is not more to do...
> > diff --git a/include/linux/types.h b/include/linux/types.h
> > index 0351bf2..d988636 100644
> > --- a/include/linux/types.h
> > +++ b/include/linux/types.h
> > @@ -34,6 +34,8 @@ typedef __kernel_mqd_t                mqd_t;
> >
> >  #ifdef __KERNEL__
> >  typedef _Bool                  bool;
> > +#define TRUE                   1
> > +#define FALSE                  0

> First of, I believe this should be in stddef.h (as 'false'/'true'/NULL).

i agree, but that's not the issue here.  the issue is what is *in* the
source tree, now what people someday agree on what will eventually be
there.

> Second, why add a second definition of false and true? I have yet to
> hear someone wanting upper-cast instead of lower (0/1 yes, but not
> upper-cast).

*these* people want upper case:

  $ grep -rw TRUE .

and, no, as i said, it's not an issue of what the standard will be
*some day*, it's what is in the tree *today* and, with a small patch,
a whole whack of useless defines of TRUE and FALSE can be deleted,
while having absolutely no effect on what people eventually decide
what to do about this.

> Actually some would like it to be 'null' instead of NULL :)

and *i* would like a date with jessica alba.

> Just, what is the rush to remove that "crap"? It's been there for
> quite some time and will be taken care of when converted to a
> generic boolean.

and the thread discussing this happened months ago, and nothing
happened.  and -- one more time -- the patch above doesn't even
*attempt* to standardize what will eventually be used for booleans.
it simply allows all of the redundant defines -- which have to be
removed *anyway* -- to be removed *now* while the powers that be
continue to ruminate on this for the *next* several months.  or years.

rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Robert P. J. Day]

  by the way, part of my style script looks for code that insists on
redefining booleans in one way or another.  at the moment, it looks
like this:

$ grep -ri "^typedef.*bool" .
./drivers/scsi/BusLogic.h:typedef bool boolean;
./drivers/scsi/pci2000.h:typedef        BOOL    *PBOOL;
./drivers/telephony/ixj.h:typedef __u8 BOOL;
./drivers/block/DAC960.h:typedef bool boolean;
./drivers/video/riva/riva_hw.h:typedef int Bool;
./drivers/video/sis/vgatypes.h:typedef unsigned int BOOLEAN;
./arch/parisc/math-emu/float.h:typedef int boolean;
./include/acpi/actypes.h:typedef unsigned char BOOLEAN;
./include/linux/types.h:typedef _Bool                   bool;
./include/linux/efi.h:typedef u8 efi_bool_t;
./include/linux/efi.h:typedef efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, efi_bool_t *pending,
./include/linux/efi.h:typedef efi_status_t efi_set_wakeup_time_t (efi_bool_t enabled, efi_time_t *tm);
./fs/xfs/xfs_types.h:typedef enum { B_FALSE,B_TRUE }    boolean_t;

 did you want to submit a patch to clean up any of that, if it can be
done at the moment?

rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Richard Knutsson]

Robert P. J. Day wrote:
>   by the way, part of my style script looks for code that insists on
> redefining booleans in one way or another.  at the moment, it looks
> like this:
>
> $ grep -ri "^typedef.*bool" .
>   
Is the script also checking for booleans defined by "#define" or "enum" 
(without typedef)?
> ./drivers/scsi/BusLogic.h:typedef bool boolean;
>   
Sent a patch on this one yesterday to LKML.
> ./drivers/scsi/pci2000.h:typedef        BOOL    *PBOOL;
> ./drivers/telephony/ixj.h:typedef __u8 BOOL;
> ./drivers/block/DAC960.h:typedef bool boolean;
>   
How did I miss this one?
> ./drivers/video/riva/riva_hw.h:typedef int Bool;
> ./drivers/video/sis/vgatypes.h:typedef unsigned int BOOLEAN;
> ./arch/parisc/math-emu/float.h:typedef int boolean;
> ./include/acpi/actypes.h:typedef unsigned char BOOLEAN;
> ./include/linux/types.h:typedef _Bool                   bool;
>   
The "generic" one.
> ./include/linux/efi.h:typedef u8 efi_bool_t;
> ./include/linux/efi.h:typedef efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, efi_bool_t *pending,
> ./include/linux/efi.h:typedef efi_status_t efi_set_wakeup_time_t (efi_bool_t enabled, efi_time_t *tm);
> ./fs/xfs/xfs_types.h:typedef enum { B_FALSE,B_TRUE }    boolean_t;
>   
Have sent them a patch before but they seemed not too interested for the 
moment. Will come back when most of the cleanup is done.
>  did you want to submit a patch to clean up any of that, if it can be
> done at the moment?
>   
Should get DAC960.h out today. But the rest should be checked, to see if 
it is used when declaring in struct's and that struct is 
mem(cmp|cpy|move|...) (or something that may be size-sensitive).

Any help appreciated ;)
Richard Knutsson

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Robert P. J. Day]

On Mon, 22 Jan 2007, Richard Knutsson wrote:

> Robert P. J. Day wrote:
> >   by the way, part of my style script looks for code that insists
> > on redefining booleans in one way or another.  at the moment, it
> > looks like this:
> >
> > $ grep -ri "^typedef.*bool" .

> Is the script also checking for booleans defined by "#define" or
> "enum" (without typedef)?

nope.  if you look at that grep command, what you see is what you get.
i can extend the search to try to hit others.  this was meant to be
just a *very* rough first pass, to at least let someone get started.

> > ./drivers/scsi/BusLogic.h:typedef bool boolean;

> Sent a patch on this one yesterday to LKML.

yup, i saw that.  good job.

> > ./drivers/scsi/pci2000.h:typedef        BOOL    *PBOOL;
> > ./drivers/telephony/ixj.h:typedef __u8 BOOL;
> > ./drivers/block/DAC960.h:typedef bool boolean;

> How did I miss this one?

you don't have a handy-dandy "style.sh" script.  :-)

> > ./drivers/video/riva/riva_hw.h:typedef int Bool;
> > ./drivers/video/sis/vgatypes.h:typedef unsigned int BOOLEAN;
> > ./arch/parisc/math-emu/float.h:typedef int boolean;
> > ./include/acpi/actypes.h:typedef unsigned char BOOLEAN;
> > ./include/linux/types.h:typedef _Bool                   bool;

> The "generic" one.

i didn't try to do any clever filtering, so that "grep" command is
bound to produce a few false positives, which i just ignore.

> > ./include/linux/efi.h:typedef u8 efi_bool_t;
> > ./include/linux/efi.h:typedef efi_status_t efi_get_wakeup_time_t (efi_bool_t
> > *enabled, efi_bool_t *pending,
> > ./include/linux/efi.h:typedef efi_status_t efi_set_wakeup_time_t (efi_bool_t
> > enabled, efi_time_t *tm);
> > ./fs/xfs/xfs_types.h:typedef enum { B_FALSE,B_TRUE }    boolean_t;
> >
> Have sent them a patch before but they seemed not too interested for
> the moment. Will come back when most of the cleanup is done.

that sounds pretty typical.

> >  did you want to submit a patch to clean up any of that, if it can
> > be done at the moment?
> >
> Should get DAC960.h out today. But the rest should be checked, to
> see if it is used when declaring in struct's and that struct is
> mem(cmp|cpy|move|...) (or something that may be size-sensitive).

that's a good point but it seems to me that anyone who declares
something of type "boolean" of some kind shouldn't be trying to
squeeze in any size-sensitive information there.  any variant of a
"boolean" which requires anything beyond being able to hold the two
values of TRUE or FALSE strikes me as broken.

> Any help appreciated ;)

if someone wants to jump in here, feel free.  i'll go back and see if
i can broaden the search of my script to see what else i can find.


rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] standardizing on boolean variables?

[Robert P. J. Day]

On Mon, 22 Jan 2007, Richard Knutsson wrote:

> Is the script also checking for booleans defined by "#define" or
> "enum" (without typedef)?

here's a list of files that insist on defining their own boolean
values of some kind using enums:

./drivers/net/wireless/strip.c:enum { FALSE = 0, TRUE = 1 };

./arch/arm/nwfpe/milieu.h-enum {
./arch/arm/nwfpe/milieu.h-    FALSE = 0,
./arch/arm/nwfpe/milieu.h:    TRUE  = 1
./arch/arm/nwfpe/milieu.h-};

./arch/arm26/nwfpe/milieu.h-enum {
./arch/arm26/nwfpe/milieu.h-    FALSE = 0,
./arch/arm26/nwfpe/milieu.h:    TRUE  = 1
./arch/arm26/nwfpe/milieu.h-};

./fs/xfs/linux-2.6/xfs_vnode.h:typedef enum { L_FALSE, L_TRUE } lastclose_t;


rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors