[patch] WORDSIZE dependant printf length modifiers

Rob Landley rob at landley.net
Mon Apr 10 01:31:49 UTC 2006


On Saturday 08 April 2006 4:32 pm, Robert P. J. Day wrote:
> On Sat, 8 Apr 2006, Rob Landley wrote:
> > On Saturday 08 April 2006 4:43 am, Robert P. J. Day wrote:
> > > and declaring boolean variables as some type of actual "boolean"
> > > definitely improves the code aesthetics and, possibly, type
> > > checking.
> >
> > It somehow improves the code to use a type that has a profoundly
> > undefined representation?
>
> i'm not sure what the problem is here.  what does the representation
> have to do with anything?  doesn't it make sense that, if you want a
> data type to represent exactly one of two boolean values, you declare
> it as of type "boolean"?  in what way would that be a bad thing?

For about three years in the late 90's, java was my primary programming 
language.  In java, boolean actually is a different primitive type, in that 
== returns a boolean, if expects a boolean (and will warn if it doesn't get 
it), etc.  It's fundamental and pervasive, and makes sense in context.

You, however, are talking about using this piece of Sun brain damage:
/usr/include/rpc/types.h:typedef int bool_t;

That's an integer.  There is absolutely _nothing_ preventing code from 
assigning "147" to that, and people using it are likely to think "oh, 
boolean, that's not a whole 4 bytes".

By the way, that's not the c99 type.  It seems that c99 has both "bool" and 
"_Bool":

http://lists.samba.org/archive/samba-technical/2003-April/028795.html
http://www.comeaucomputing.com/techtalk/c99/#bool

But what did gcc do with it?
http://gcc.gnu.org/ml/gcc-patches/2000-10/msg01127.html

That implies it's a char internally, which is going to suck mightily on 
platforms that don't allow unaligned access.  And my headers in ubuntu don't 
seem to have stdbool.h, and I'm kind of happy about this actually.

I'm just not going there.  I see absolutely no advantages of this.  It takes 
control _away_ from the programmer.  It hides from us what we're actually 
doing.  Aesthetically, it's right up there with "#define begin {" and 
"#define end }" for ex-pascal programmers.

No.

> rday

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list