nanogui: Thread: typedef int MWBOOL;


[<<] [<] Page 1 of 1 [>] [>>]
Subject: typedef int MWBOOL;
From: Dave Poirier ####@####.####
Date: 4 Jan 2002 03:53:14 -0000
Message-Id: <20020104035107.GA21033@void-core.2y.net>

I'm currently working on a project of porting nano-X to another
operating system and I came across this typedef, which seems like a
little huge for its use.

Unless I'm mistaken, a boolean value take either the value "true" or
"false", some prefer to use "1" or "0", etc.  But in all cases, it has
only 2 possible values, shouldn't a unsigned char be more than
sufficient to store it instead a wasting 4 bytes of data for it?

ref: include/mwtypes.h
-- 
EKS - Dave Poirier                               ####@####.####
"may the hairs on his toes never fall out"           http://uuu.sf.net/
Subject: Re: [nanogui] typedef int MWBOOL;
From: "Greg Haerr" ####@####.####
Date: 4 Jan 2002 05:58:50 -0000
Message-Id: <005701c194e3$849c3000$3aba46a6@xmission.com>

: Unless I'm mistaken, a boolean value take either the value "true" or
: "false", some prefer to use "1" or "0", etc.  But in all cases, it has
: only 2 possible values, shouldn't a unsigned char be more than
: sufficient to store it instead a wasting 4 bytes of data for it?

The reason for this has to do with some old-time issues
with C compilers.  Take the following function:

int a = -1;

unsigned char f(void)
{
    return a;
}

vs

int f(void)
{
    return a;
}

if MWBOOL is used completely arbitrarily, such as for the use of
function return values, then it's a much better idea to declare a function
returning int than char, for sign extension and other old-fashioned C 
reasons.  It is for this reason and other similar reasons 
that most other software systems will always
typedef a boolean to be an int, rather than a char size. 
Many systems have big issues with taking the address of a char
sized parameter, placed as an int on the stack, as well.  There are
too many problems with older C compilers to use a "char" data
type for anything other than a known packed array.

Regards,

Greg

Subject: Re: [nanogui] typedef int MWBOOL;
From: Jordan Crouse ####@####.####
Date: 4 Jan 2002 16:05:12 -0000
Message-Id: <E16MWoD-0001Fg-00@ns.censoft.com>

Whats more, MWBOOL is usually used in either a stack or register context, so 
size isn't really an issue.  Its not like we're allocating huge chunks of 
MWBOOLs on the heap somewhere.

Jordan  

On Thursday 03 January 2002 22:49, Greg Haerr mentioned:
> : Unless I'm mistaken, a boolean value take either the value "true" or
> : "false", some prefer to use "1" or "0", etc.  But in all cases, it has
> : only 2 possible values, shouldn't a unsigned char be more than
> : sufficient to store it instead a wasting 4 bytes of data for it?
>
> The reason for this has to do with some old-time issues
> with C compilers.  Take the following function:
>
> int a = -1;
>
> unsigned char f(void)
> {
>     return a;
> }
>
> vs
>
> int f(void)
> {
>     return a;
> }
>
> if MWBOOL is used completely arbitrarily, such as for the use of
> function return values, then it's a much better idea to declare a function
> returning int than char, for sign extension and other old-fashioned C
> reasons.  It is for this reason and other similar reasons
> that most other software systems will always
> typedef a boolean to be an int, rather than a char size.
> Many systems have big issues with taking the address of a char
> sized parameter, placed as an int on the stack, as well.  There are
> too many problems with older C compilers to use a "char" data
> type for anything other than a known packed array.
>
> Regards,
>
> Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.