using char as boolean data type

[Ramprasad A Padmanabhan]

Hello all,

On my linux box ( redhat 7.2 ), I have been using char as a boolean data
type. In order to save on the number of bytes as compared to using int
or short int.

typedef char boolean;

boolean x;
x=1;
.....


if(x){
/* x is true */
} else {
/* x is false */
}
}
Is this usage of valid on all platforms. I will be happy If this will work
on all linux distributions at least.

Thanks
Ram

 

[Derk Gwen]

# Hello all,
#
# On my linux box ( redhat 7.2 ), I have been using char as a boolean data
# type. In order to save on the number of bytes as compared to using int
# or short int.
#
# typedef char boolean;
#
# boolean x;
# x=1;
# ....
#
#
# if(x){
# /* x is true */
# } else {
# /* x is false */
# }
# }
# Is this usage of valid on all platforms.

Yes.

 

[Irrwahn Grausewitz]

typedef char boolean;

boolean x;
x=1;
....


if(x){
/* x is true */
} else {
/* x is false */
}
}
Is this usage of valid on all platforms. I will be happy If this will work
on all linux distributions at least.

I cannot think of any problems with that code running on any conforming
implementation I can think of.

If I'm wrong, the c.l.c regulars will hopefully correct me.

However, hiding a simple type behind a typename is considered bad style
by some programmers - why not use char in the first place?

Irrwahn

 

[news.cis.dfn.de]

I cannot think of any problems with that code running on any conforming
implementation I can think of.

If I'm wrong, the c.l.c regulars will hopefully correct me.

However, hiding a simple type behind a typename is considered bad style
by some programmers - why not use char in the first place?

Irrwahn

I typedef is just to avoid confusion.
Like char x;
x = 1;
/* Though it works It seems logical only to have int types set to 1 */


Ram

 

[Ramprasad A Padmanabhan]

I cannot think of any problems with that code running on any conforming
implementation I can think of.

If I'm wrong, the c.l.c regulars will hopefully correct me.

However, hiding a simple type behind a typename is considered bad style
by some programmers - why not use char in the first place?

Irrwahn

I typedef only to avoid confusion
like
char x = 1;
/* Nothing wrong, but char x = any character is what is logical */


Ram

 

[Irrwahn Grausewitz]

I typedef only to avoid confusion
like
char x = 1;
/* Nothing wrong, but char x = any character is what is logical */

This depends on your POV. Nothing is 'wrong' with one or the other -
as you said.

 

[Mike Copeland]

On my linux box ( redhat 7.2 ), I have been using char as a boolean data

type. In order to save on the number of bytes as compared to using int
or short int.

typedef char boolean;

boolean x;
x=1;
....


if(x){
/* x is true */
} else {
/* x is false */
}
}
Is this usage of valid on all platforms. I will be happy If this will work
on all linux distributions at least.

As others have said, it's okay. However, I infer from your query that
you're looking to optimize code/size of executable, and that may not be
happening as you think. Yes, using the char variable may use less of a
_structure_data_, but it's entirely possible that the _code_generated_ to
access it may be significantly more than if it were an int. This is
because on many machines - and I can't say such for your hardware and
Redhat Linux - the "native mode" data access is 32 bits. Hence the int
default data type for boolean...
Thus, while you're saving 16 bits of storage space, it's quite
possible that the runtime code to access and manipulate the non-native
data element is costing you much more. Also, you can't be sure of the
_alignment_ it's getting, and you might not be saving any data space at
all!
The issue most likely is the _amount_ of space you're "saving" with
this action: if you have thousands of these variables (or such), it's
probably a "win"; if you just have a few of them, I'd bet you're having a
"regressive improvement" with this choice. Another concern is the number
of accesses you're applying: the extra code generated for the char data
(versus int) is probably an item to consider.
Bottom line: I'd have to need a good reason to do this sort of
thing...

 

[Ramprasad A Padmanabhan]

As others have said, it's okay. However, I infer from your query that
you're looking to optimize code/size of executable, and that may not be
happening as you think. Yes, using the char variable may use less of a
_structure_data_, but it's entirely possible that the _code_generated_ to
access it may be significantly more than if it were an int. This is
because on many machines - and I can't say such for your hardware and
Redhat Linux - the "native mode" data access is 32 bits. Hence the int
default data type for boolean...
Thus, while you're saving 16 bits of storage space, it's quite
possible that the runtime code to access and manipulate the non-native
data element is costing you much more. Also, you can't be sure of the
_alignment_ it's getting, and you might not be saving any data space at
all!
The issue most likely is the _amount_ of space you're "saving" with
this action: if you have thousands of these variables (or such), it's
probably a "win"; if you just have a few of them, I'd bet you're having a
"regressive improvement" with this choice. Another concern is the number
of accesses you're applying: the extra code generated for the char data
(versus int) is probably an item to consider.
Bottom line: I'd have to need a good reason to do this sort of
thing...

Right sir,

I am using this script in a milter program that runs as a daemon
listening on a socket. I use around 10-20 boolean flags in the entire
daemon depending on what options are chosen. So Is it better to have
boolean as int.

Now these flags are a part of my structure and memory for it is
'malloced' every instance so will mallocing ( and freeing in the end ) a
larger structure take more resources ( CPU and memory ).

My problem is the milter does take some load on the machine and I
looking on to optimize the code.

Thanks
Ram

 

[pete]

C:\Program Files\DevStudio\SharedIDE\bin\Debug>new
Bit 0 of flags, is set.
Bit 3 of flags, is set.
Bit 4 of flags, is set.
Bit 30 of flags, is set.

/* BEGIN flags.c */

#include <stdio.h>

#define READ_LUBIT(F,N) (((F) & 1LU << (N)) != 0)
#define SET_LUBIT(F,N) ((F) |= 1LU << (N))
#define CLEAR_LUBIT(F,N) ((F) &= ~(1LU << (N)))
#define FLIP_LUBIT(F,N) ((F) ^= 1LU << (N))

#define MIN_BITS 32

int main(void)
{
long unsigned flags = 0;
int bit;

SET_LUBIT(flags, 0);
SET_LUBIT(flags, 3);
SET_LUBIT(flags, 4);
SET_LUBIT(flags, 30);

for (bit = 0; bit != MIN_BITS; ++bit) {
if (READ_LUBIT(flags, bit)) {
printf("Bit %d of flags, is set.\n", bit);
}
}
return 0;
}

/* END flags.c */

 

[Ramprasad A Padmanabhan]

Ramprasad A Padmanabhan wrote:




C:\Program Files\DevStudio\SharedIDE\bin\Debug>new
Bit 0 of flags, is set.
Bit 3 of flags, is set.
Bit 4 of flags, is set.
Bit 30 of flags, is set.

/* BEGIN flags.c */

#include <stdio.h>

#define READ_LUBIT(F,N) (((F) & 1LU << (N)) != 0)
#define SET_LUBIT(F,N) ((F) |= 1LU << (N))
#define CLEAR_LUBIT(F,N) ((F) &= ~(1LU << (N)))
#define FLIP_LUBIT(F,N) ((F) ^= 1LU << (N))

#define MIN_BITS 32

int main(void)
{
long unsigned flags = 0;
int bit;

SET_LUBIT(flags, 0);
SET_LUBIT(flags, 3);
SET_LUBIT(flags, 4);
SET_LUBIT(flags, 30);

for (bit = 0; bit != MIN_BITS; ++bit) {
if (READ_LUBIT(flags, bit)) {
printf("Bit %d of flags, is set.\n", bit);
}
}
return 0;
}

/* END flags.c */

I dont want to use bits for boolean flags. I have just 10-20 flags not
milllions that I will save any memory vis a vis the processing that will
take
I read on the same newsgroup that bitwise processing is waste of cpu and
is unreasonable for a small number of variables

Ram

 

[pete]

I dont want to use bits for boolean flags. I have just 10-20 flags not
milllions that I will save any memory vis a
vis the processing that will take I read on the same newsgroup that
bitwise processing is waste of cpu and
is unreasonable for a small number of variables

You originally said that you were interested
in the number of bytes.
I see now that you are interested in saving bytes
while considering speed.
It is possible that char math may be slower than int math.

You could do timing tests, but for your situation,
I'm guessing that both the speed differences
and the memory savings are entirely inconsequential
regardless of whether you use int, char or bits
for your boolean data.