468,463 Members | 2,058 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,463 developers. It's quick & easy.

bool variable.(a non-standard question)

I have code which says

#define MYBOOL int

This code is very old. people who have written is not avaible. I was
thinking what could be reason.
1) bool datatype was not available that time (10 years back: correct me
if i am wrong)
2) int was word aligned (16bit and 32bit). Writter of above code doesnt
want to give choice to compiler.
if we say bool , compiler can represent this on his way (again,correct
me if i am wrong)
This much i can think of it.

even in many books, i have seen author using int as a flag. example
Richard Stevens, "advance programming in unix environment" . and this
book uses 'restrict' keyword.

Now, i have to change it for 64bit arch. In my system, performance is
more important thn anything else.
I thought of changing it to long on 64arch.
#define MYBOOL long

Any comment on this will be appreciated.

Sep 2 '06
64 3521
Old Wolf said:
[...] your code
won't be portable to C99 (not that you'd care, I imagine),
I do actually care about portability to C99, which is why I make sure that I
code within the common subset of C90 and C99. When C99 becomes widely
available, my code will be ready for it. And I will be very glad when C99
does become widely available. But it isn't there yet.
If you don't see the value of having a true boolean type, then
that's fine -- but other people do see the value.
If you don't see the value of writing code that can be compiled properly on
a vast range of C compilers for a great many platforms, then that's fine --
but other people do see the value.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 5 '06 #51
"Old Wolf" <ol*****@inspire.net.nzwrites:
Richard Heathfield wrote:
>I did no such thing. What I said was that the compiler I use for production
code doesn't know about _Bool. The compiler I use for production code is
gcc ***in conforming mode***, not just unadorned gcc. And in conforming
mode, gcc doesn't know about _Bool.

Invoked with the switch -std=c99, gcc is in conforming mode --
conforming to C99.
No, it isn't. See <http://gcc.gnu.org/c99status.html>.
(Please don't give me that rubbish about it not actually conforming
to C99.
Whoops, too late.
IMHO, conformance doesn't have to be 100% in order to
say that it conforms. I have a C89 compiler that doesn't
zero-initialize uninitialized static data. Does that mean that my
compiler is worthless? It seems an irrelevant semantic quibble to say
that this compiler doesn't conform to C89 because of that -- and
especially bad to say that the compiler is worthless and not
suitable for use with portable code.)
A C89 compiler that doesn't zero-initialize uninitialized static data
has a serious bug. I suppose you could still manage to use it.
Nobody said that failing to conform to a standard makes a compiler
worthless, but it does make it non-conforming.

Have you reported this bug to the implementers? Have you considered
switching to a compiler that gets this simple thing right? (If the
buggy compiler you're using has other advantages, of course, it's your
choice to continue using it.)

A compiler that conforms to C89/C90 and implements no C99-specific
features at all is *mostly* conforming to C99. Would you call such a
compiler a conforming C99 compiler?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 5 '06 #52
Keith Thompson wrote:
goose <lk************@webmail.co.zawrites:
Peter Nilsson wrote:
[In C90] I prefer...
typedef unsigned int bool;
Because you can then do robust boolean bitfields...
struct blah
{
bool flag_1 : 1;
bool flag_2 : 1;
bool flag_3 : 1;
...
};
Let me try again:
It doesn't make sense for a boolean type to have
more than a single bitfield of length 1.

I'm afraid I don't know what you're talking about.

Only a structure type (or a union?) can have bitfields.
A union member can be a bit field. 6.7.2.1p8...

A member of a structure or union may have any object type
other than a variably modified type.102) In addition, a member
may be declared to consist of a specified number of bits
(including a sign bit, if any). Such a member is called a bit-
field;103) its width is preceded by a colon.
A structure can have bitfields *of* a boolean type, but it makes no
sense for a boolean type to have bitfields -- and I don't see than
anybody suggested otherwise. ("struct blah" above is not a boolean
type.)

Can you re-phrase your point?
Yes, that would be good.

If goose means that there is no sense in having more than one
boolean bitfield in a struct, then that isn't true either. Consider
a gui 'window' struct...

struct window
{
bool visible : 1;
bool front : 1;
bool focus : 1;
bool modal : 1;
bool movable : 1;
bool resizable : 1;
bool floating : 1;
bool custom : 1;
...
};

--
Peter

Sep 5 '06 #53
Peter Nilsson said:
Keith Thompson wrote:
<snip>
>>
Only a structure type (or a union?) can have bitfields.

A union member can be a bit field. 6.7.2.1p8...
s/n be/n have/

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 5 '06 #54
Richard Heathfield wrote:
Peter Nilsson said:
Keith Thompson wrote:
<snip>
>
Only a structure type (or a union?) can have bitfields.
A union member can be a bit field. 6.7.2.1p8...

s/n be/n have/
A struct/union type can have a bitfield. A struct/union member can be a
bitfield.

Sep 5 '06 #55
Harald van D?k said:
Richard Heathfield wrote:
>Peter Nilsson said:
Keith Thompson wrote:
<snip>
>>
Only a structure type (or a union?) can have bitfields.

A union member can be a bit field. 6.7.2.1p8...

s/n be/n have/

A struct/union type can have a bitfield. A struct/union member can be a
bitfield.
Thank you. I apologise to Peter for misreading and thus miscorrecting him.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 5 '06 #56
Keith Thompson wrote:
"Old Wolf" <ol*****@inspire.net.nzwrites:
<snip>
> IMHO, conformance doesn't have to be 100% in order to
say that it conforms. I have a C89 compiler that doesn't
zero-initialize uninitialized static data. Does that mean that my
compiler is worthless? It seems an irrelevant semantic quibble to say
that this compiler doesn't conform to C89 because of that -- and
especially bad to say that the compiler is worthless and not
suitable for use with portable code.)

A C89 compiler that doesn't zero-initialize uninitialized static data
has a serious bug. I suppose you could still manage to use it.
Nobody said that failing to conform to a standard makes a compiler
worthless, but it does make it non-conforming.

Have you reported this bug to the implementers? Have you considered
switching to a compiler that gets this simple thing right? (If the
buggy compiler you're using has other advantages, of course, it's your
choice to continue using it.)
I had a compiler like that myself for a while. The TI C compiler for the
TMS320C2x/5x. Since the provided the startup code and my requirements
included adding a RAM test I added the RAM test to the startup code in
such a way that it left all of the RAM zeroed and thus made it a
conforming implementation.
A compiler that conforms to C89/C90 and implements no C99-specific
features at all is *mostly* conforming to C99. Would you call such a
compiler a conforming C99 compiler?
I agree with your points about there currently being no version of gcc
which is a conforming C99 compiler even if one ignores the library issue.
--
Flash Gordon
Sep 5 '06 #57
Keith Thompson wrote:
goose <lk************@webmail.co.zawrites:
Keith Thompson wrote:
goose <lk************@webmail.co.zawrites:

Peter Nilsson wrote:

Richard Heathfield wrote:
... Of course, apart from a bitfield (of type unsigned int and
width 1), there is no [C90] type that can /only/ take a value
from the range [0, 1], and a bitfield would be unlikely to win
any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;

I prefer...
typedef unsigned int bool;
Because you can then do robust boolean bitfields...
struct blah
{
bool flag_1 : 1;
bool flag_2 : 1; bool flag_3 : 1;
...
};
It doesn't make sense for a boolean type to have *bitfields*,
so I'd rather just do "typedef int bool;".
Why doesn't it make sense? In C99, bit fields of type _Bool are
legal
(and limited to a width of 1 bit). It seems perfectly sensible to me.
Limited to width of 1, yes that makes sense.

Let me try again:
It doesn't make sense for a boolean type to have
more than a single bitfield of length 1.

I'm afraid I don't know what you're talking about.
Oh dear. This means that either I wasn't clear or
I'm full of brown smelly stuff :-(
>
Only a structure type (or a union?) can have bitfields. A structure
can have bitfields *of* a boolean type, but it makes no sense for a
boolean type to have bitfields -- and I don't see than anybody
suggested otherwise. ("struct blah" above is not a boolean type.)

Can you re-phrase your point?
typedef unsigned int bool;
....
struct foo
{
bool bar : 1; /* makes sense */
bool bar : 2; /* doesn't make sense, but now allowed */
}

I say "doesn't make sense" because we typedef'ed a
boolean and then want to go ahead and use bitfields
of them that go beyond the range that we /intended/
with "bool".

Maybe what I should say is that it is inconsistent?
If we are able to do

struct structname {
typename variablename : width;
};

with the restriction that width is not greater
than the width of the typename, using bool with
a width other than 1 breaks *my* mental model
of what bool is (I suddenly have to go look it
up). For instance if width is 9, I have to
hunt down the typedef of bool to ensure that
it isn't typedef'ed as "unsigned char".

All that can be avoided if you use "unsigned int"
for bitfields other than 1; while we're about it,
why hide "unsigned int" behind "bool" for a
width of 1 - we may as well just use unsigned int
for width=1 as well[1].

Not saying that it isn't legal C, but that it
introduces too many special cases if we use
a typedef'ed bool for a bitfield.

Please, correct me if I'm wrong - it's bloody
embarrassing walking around with misconceptions :-)
goose,
hopefully I've got *too* many misconceptions.

Sep 6 '06 #58

Keith Thompson wrote:
"Peter Nilsson" <ai***@acay.com.auwrites:
Richard Heathfield wrote:
... Of course, apart from a bitfield (of type unsigned int and
width 1), there is no [C90] type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;
I prefer...

typedef unsigned int bool;

Because you can then do robust boolean bitfields...

struct blah
{
bool flag_1 : 1;
bool flag_2 : 1;
bool flag_3 : 1;
...
};

Since C99 uses the name "bool", I wouldn't use that identifier in C90
code. It won't cause any problems for the compiler, since C99
carefully added a new keyword _Bool and declared "bool" only in the
new <stdbool.hheader, but it could still cause confusion for the
reader.

And I'd prefer to use "unsigned int" directly for bit fields:

struct blah {
unsigned flag_1 : 1;
unsigned flag_2 : 1;
unsigned flag_3 : 1;
...
};

since I know that int, signed int, and unsigned int are the only
portably legal types for bit fields in C90.

On the other hand, I suppose a case could be made for using "bool" if
you're trying to be compatible with both C90 and C99.
A problem there is that the two semantics are different.

struct {
unsigned u : 1;
_Bool b : 1;
} s;

s.u = 2;
s.b = 2;

After the assignments, s.u == 0, but the
value s.b == 1.

Sep 6 '06 #59

Richard Heathfield wrote:
en******@yahoo.com said:

<snip>
Of course a C compiler told to
compile C90 doesn't know about _Bool, any more
than Fortran or Pascal compilers do.

Quite so.
Just admit that _Bool is available

It may well be available, but it is not /widely/ available. For example, it
isn't available in /any/ of the conforming implementations I have readily
to hand.
but you prefer not to use
compilers that don't fully support C99 (or whatever
it is that you do prefer).

I would be delighted to use a compiler that fully supports C99, just as soon
as they become widely available, which hasn't happened yet and isn't likely
to happen for some years, if not decades. In the meantime, since I prefer
to write code that is widely portable, I avoid C99-only features.
I don't have any problem with you wanting to use a fully
supported standard. And I admit that gcc, in any version
I'm aware of, does not fully support C99.

What does bother me is your apparent willingness to tilt
your definitions and conclusions to support that position.
It's not intellectually honest. Certainly gcc is widely
available. Certainly gcc that supports --std=c99 is in
common use (it's here in my very old version of Linux).
Certainly gcc that supports _Bool, even if it isn't in
common use, can be downloaded off the net and compiled, and
in that sense it is certainly widely _available_. Available
doesn't mean in use or desirable; it means available.
Whether gcc fully supports C99 has no bearing on whether it
supports _Bool, or how widely available it is.

There's no need to convince me your position is reasonable;
I already think it's reasonable. But the kinds of arguments
you use make your position less convincing, not more.

Sep 6 '06 #60

Keith Thompson wrote:
goose <lk************@webmail.co.zawrites:
Peter Nilsson wrote:
Richard Heathfield wrote:

... Of course, apart from a bitfield (of type unsigned int and
width 1), there is no [C90] type that can /only/ take a value from the range
[0, 1], and a bitfield would be unlikely to win any awards for speed.

If speed is at a premium, he should choose int:

typedef int bool;
I prefer...
typedef unsigned int bool;
Because you can then do robust boolean bitfields...
struct blah
{
bool flag_1 : 1;
bool flag_2 : 1; bool flag_3 : 1;
...
};
It doesn't make sense for a boolean type to have *bitfields*,
so I'd rather just do "typedef int bool;".

Why doesn't it make sense? In C99, bit fields of type _Bool are legal
(and limited to a width of 1 bit). It seems perfectly sensible to me.
Does the Standard actually say anywhere that bitfields
of type _Bool may use only :1? Or are you saying
something else?

Sep 6 '06 #61

Richard Heathfield wrote:
Old Wolf said:
[...] your code
won't be portable to C99 (not that you'd care, I imagine),

I do actually care about portability to C99, which is why I make sure that I
code within the common subset of C90 and C99. When C99 becomes widely
available, my code will be ready for it. And I will be very glad when C99
does become widely available. But it isn't there yet.
If you don't see the value of having a true boolean type, then
that's fine -- but other people do see the value.

If you don't see the value of writing code that can be compiled properly on
a vast range of C compilers for a great many platforms, then that's fine --
but other people do see the value.
If what you want is to write code in the intersection of
C90 and C99, wouldn't it make sense to get a compiler
that supports C99 (even if only partially), and run your
code through both compilers? C99 has semantic restrictions
that C90 does not.

I usually write code that is (at least mostly) in the
C90 subset of C99.

Sep 6 '06 #62

goose wrote:
Keith Thompson wrote:
goose <lk************@webmail.co.zawrites:
Keith Thompson wrote:
>goose <lk************@webmail.co.zawrites:
>>
>>>Peter Nilsson wrote:
>>>
>>>>Richard Heathfield wrote:
>>>>
>>>>
>>>>>... Of course, apart from a bitfield (of type unsigned int and
>>>>>width 1), there is no [C90] type that can /only/ take a value
>>>>>from the range [0, 1], and a bitfield would be unlikely to win
>>>>>any awards for speed.
>>>>>
>>>>>If speed is at a premium, he should choose int:
>>>>>
>>>>>typedef int bool;
>>>>
>>>>I prefer...
>>>typedef unsigned int bool;
>>>>Because you can then do robust boolean bitfields...
>>> struct blah
>>> {
>>> bool flag_1 : 1;
>>> bool flag_2 : 1; bool flag_3 : 1;
>>> ...
>>> };
>>>>
>>>
>>>It doesn't make sense for a boolean type to have *bitfields*,
>>>so I'd rather just do "typedef int bool;".
>Why doesn't it make sense? In C99, bit fields of type _Bool are
>legal
>(and limited to a width of 1 bit). It seems perfectly sensible to me.

Limited to width of 1, yes that makes sense.
>
Let me try again:
It doesn't make sense for a boolean type to have
more than a single bitfield of length 1.
I'm afraid I don't know what you're talking about.

Oh dear. This means that either I wasn't clear or
I'm full of brown smelly stuff :-(

Only a structure type (or a union?) can have bitfields. A structure
can have bitfields *of* a boolean type, but it makes no sense for a
boolean type to have bitfields -- and I don't see than anybody
suggested otherwise. ("struct blah" above is not a boolean type.)

Can you re-phrase your point?

typedef unsigned int bool;
...
struct foo
{
bool bar : 1; /* makes sense */
bool bar : 2; /* doesn't make sense, but now allowed */
}

I say "doesn't make sense" because we typedef'ed a
boolean and then want to go ahead and use bitfields
of them that go beyond the range that we /intended/
with "bool".

Maybe what I should say is that it is inconsistent?
If we are able to do

struct structname {
typename variablename : width;
};

with the restriction that width is not greater
than the width of the typename, using bool with
a width other than 1 breaks *my* mental model
of what bool is (I suddenly have to go look it
up). For instance if width is 9, I have to
hunt down the typedef of bool to ensure that
it isn't typedef'ed as "unsigned char".

All that can be avoided if you use "unsigned int"
for bitfields other than 1; while we're about it,
why hide "unsigned int" behind "bool" for a
width of 1 - we may as well just use unsigned int
for width=1 as well[1].

Not saying that it isn't legal C, but that it
introduces too many special cases if we use
a typedef'ed bool for a bitfield.

Please, correct me if I'm wrong - it's bloody
embarrassing walking around with misconceptions :-)
goose,
hopefully I've got *too* many misconceptions.
It's simple: if you want unsigned semantics,
use unsigned (length :1 or otherwise); if
you want _Bool semantics, use _Bool (or bool
after the appropriate include).

To get _Bool semantics without _Bool, use

typedef unsigned c90bool;

struct {
c90bool x:1;
} s;

s.x = !!(expression);

Sep 6 '06 #63
"goose" <ru**@webmail.co.zawrites:
Keith Thompson wrote:
[...]
>Can you re-phrase your point?

typedef unsigned int bool;
...
struct foo
{
bool bar : 1; /* makes sense */
bool bar : 2; /* doesn't make sense, but now allowed */
}

I say "doesn't make sense" because we typedef'ed a
boolean and then want to go ahead and use bitfields
of them that go beyond the range that we /intended/
with "bool".
Ok, I completely agree with that. A bit field of type "bool"
shouldn't be larger than 1 bit. In C90, "bool" can be a typedef for
unsigned int, and the compiler won't enforce the 1-bit restriction.
In C99, "bool" is declared in <stdbool.has a typedef for _Bool, and
the compiler *will* enforce the restriction. If you want bit fields
bigger than one bit, don't call them "bool".

And there's nothing wrong with having multiple 1-bit "bool" bit fields
in the same structure:

struct foo {
bool foo : 1; /* ok */
bool bar : 1; /* ok */
};

Your original statement was unclear, but I agree with what you
actually meant.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 6 '06 #64
en******@yahoo.com writes:
Keith Thompson wrote:
>goose <lk************@webmail.co.zawrites:
[...]
It doesn't make sense for a boolean type to have *bitfields*,
so I'd rather just do "typedef int bool;".

Why doesn't it make sense? In C99, bit fields of type _Bool are legal
(and limited to a width of 1 bit). It seems perfectly sensible to me.
It's a matter of phrasing (and goose later re-phrased his point to
make it clear what he actually meant). A boolean type can't have
bitfields. Only a struct or union type can have bitfields. A
bitfield can have a boolean type.
Does the Standard actually say anywhere that bitfields
of type _Bool may use only :1?
[...]

Yes.

n1124 6.7.2.1p3:

The expression that specifies the width of a bit-field shall be an
integer constant expression with a nonnegative value that does not
exceed the width of an object of the type that would be specified
were the colon and expression omitted.

But this paragraph was changed post-C99. Here's what C99 6.7.2.1p3
says:

The expression that specifies the width of a bit-field shall be an
integer constant expression that has nonnegative value that shall
not exceed the number of bits in an object of the type that is
specified if the colon and expression are omitted.

An *object* of type _Bool has at least 8 bits, so C99 allows
struct {
bool foo:8;
};
but n1124 disallows this.

C99 6.2.6.2 defines "width":

The _precision_ of an integer type is the number of bits it uses
to represent values, excluding any sign and padding bits. The
_width_ of an integer type is the same but including any sign bit;
thus for unsigned integer types the two values are the same, while
for signed integer types the width is one greater than the
precision.

I'm fairly sure this implies that the width of _Bool is 1.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 6 '06 #65

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.