Can I use unsigned char as int?

[poison.summer]

For instance, I'd like to use unsigned char as an 8-bit integer.
Can I use like

unsigned char a=0;
a++


Thanks a lot!

 

[Emmanuel Delahaye]

For instance, I'd like to use unsigned char as an 8-bit integer.
Can I use like

unsigned char a=0;
a++

Technically, yes. The guaranteed minimum range is 0-255. But I don't
recommand this practice. char are not 'natural sized' and some extra
assembly code may be generated to deal with the reduced size... (extra
masquing, sign extension when signed etc.)

I recommend the use of int or unsigned int for a more efficient code.
However, small integers (like char) can be useful for arrays to reduce
the memory print, if the extra code is not a problem in terms of
performance. We often have to make a choice between execution
efficiency and memory size...

Another point. Defining a parameter as char is pointeless. It will
always be converted to an int and will use an int print in automatic
memory.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++

 

[poison.summer]

Thanks a lot! I am cooperating with others.
other people have defined
#define Byte unsigned char

so I have to use it.

So is the following a better way?
Byte a;
unsigned short tmp;
if(tmp>256)
tmp = 0;
tmp ++
a = tmp;

 

[Kenneth Brody]

Emmanuel Delahaye wrote:
[...]

Another point. Defining a parameter as char is pointeless. It will
always be converted to an int and will use an int print in automatic
memory.

Is this strictly true?

Given the following:

void foo(char c)
{
... do stuff with 'c' ...
}

void myfunc(void)
{
foo('a');
}

Assuming 32-bit ints and the ASCII character set, must the compiler
generate code that passes 0x00000061 to foo?

I have seen compilers which will load 0x61 into the low byte of a
register and push that register onto the stack, leaving the rest of
the register alone. Yes, it did push a 32-bit value, but the top
24 bits were in an undetermined state.

Were these compilers broken, as far as the standard goes?

And, strictly speaking, would it be legal for a C compiler to generate
code which pushed a 16-bit value on the stack on a system with 32-bit
integers?


--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Alexei A. Frounze]

....

Assuming 32-bit ints and the ASCII character set, must the compiler
generate code that passes 0x00000061 to foo?

I have seen compilers which will load 0x61 into the low byte of a
register and push that register onto the stack, leaving the rest of
the register alone. Yes, it did push a 32-bit value, but the top
24 bits were in an undetermined state.

Were these compilers broken, as far as the standard goes?

Probably not. I think Emmanuel only meant that physically the char value
still occupies as much on stack (when passed as an argument) as an int. Just
that.

And, strictly speaking, would it be legal for a C compiler to generate
code which pushed a 16-bit value on the stack on a system with 32-bit
integers?

Well, if it supports that 16-bit type (e.g. short) and can address a 16-bit
memory cell, why not?

Alex

 

[Keith Thompson]

Emmanuel Delahaye wrote:
[...]

Another point. Defining a parameter as char is pointeless. It will
always be converted to an int and will use an int print in automatic
memory.

Is this strictly true?
No.

Given the following:

void foo(char c)
{
... do stuff with 'c' ...
}

void myfunc(void)
{
foo('a');
}

Assuming 32-bit ints and the ASCII character set, must the compiler
generate code that passes 0x00000061 to foo?

No, if there's a mechanism for passing a single byte, it can be used
here. (This isn't the best example, since character constants are of
type int; replacing foo('a') with foo(obj), where obj is a char
object, would show what's going on more clearly.)

If there's no prototype in scope, or if the called function has a
prototype with "..." (such as printf), a char will be promoted to int,
but that doesn't apply in this case.

I have seen compilers which will load 0x61 into the low byte of a
register and push that register onto the stack, leaving the rest of
the register alone. Yes, it did push a 32-bit value, but the top
24 bits were in an undetermined state.

Were these compilers broken, as far as the standard goes?

There's no problem as long as the generated code behaves properly.

And, strictly speaking, would it be legal for a C compiler to generate
code which pushed a 16-bit value on the stack on a system with 32-bit
integers?

Yes.

 

[Chris Croughton]

Emmanuel Delahaye wrote:
[...]

Another point. Defining a parameter as char is pointeless. It will
always be converted to an int and will use an int print in automatic
memory.

Is this strictly true?

Only if there is no prototype or it is a variadic function (parameter
list ends with ... and those parameters are accessed using va_arg). So
for instance passing a char to printf() will indeed be promoted to an
int, but...

Given the following:

void foo(char c)
{
... do stuff with 'c' ...
}

void myfunc(void)
{
foo('a');
}

.... in this case foo() has a prototype in scope so it will be passed as
a char. Which may...

I have seen compilers which will load 0x61 into the low byte of a
register and push that register onto the stack, leaving the rest of
the register alone. Yes, it did push a 32-bit value, but the top
24 bits were in an undetermined state.

.... do that, or it might push a char onto the stack on some machines
which allow that, or it might pass the value in an 8 bit register, or
whatever the implementers felt was best. A compiler could even pass all
parameters as pointers and do the appropriate dereferencing in the
function as long as the code acts "as if" the parameters are passed by
value.

Were these compilers broken, as far as the standard goes?
No.

And, strictly speaking, would it be legal for a C compiler to generate
code which pushed a 16-bit value on the stack on a system with 32-bit
integers?

Yup. If the machine architecture allows it (it doesn't cause an
alignment problem) that's fine. For that matter, if you had a function
with prototype

void func(char a, char b, char c, char d);

the compiler could pack all 4 chars into a single register and pass that
in or push them all on the stack. Or it could allocate space on the
stack for all of the parameters and then write the values into that
space. It doesn't matter, as long as the calling system matches the
called code (which might be specified as a system calling convention)
the compiler can do whatever it likes.

Chris C

 

[Joe Wright]

Thanks a lot! I am cooperating with others.
other people have defined
#define Byte unsigned char

so I have to use it.

So is the following a better way?
Byte a;
unsigned short tmp;
if(tmp>256)
tmp = 0;
tmp ++
a = tmp;

Cooperation need not mean subordination. Speak Out. #define is not the
right way to do this. Consider..

typedef unsigned char Byte;
Byte a;

unsigned short tmp; /* Are you missing the assignment? */
if (tmp > 256) /* The value of tmp is indeterminate (who knows) */
tmp = 0;
tmp++; /* What can you expect here? */
a = tmp;

I give up. What was the question?

 

[Neil Kurzman]

Emmanuel Delahaye wrote:
[...]

Another point. Defining a parameter as char is pointeless. It will
always be converted to an int and will use an int print in automatic
memory.

Is this strictly true?

Given the following:

void foo(char c)
{
... do stuff with 'c' ...
}

void myfunc(void)
{
foo('a');
}

Assuming 32-bit ints and the ASCII character set, must the compiler
generate code that passes 0x00000061 to foo?

I have seen compilers which will load 0x61 into the low byte of a
register and push that register onto the stack, leaving the rest of
the register alone. Yes, it did push a 32-bit value, but the top
24 bits were in an undetermined state.

Were these compilers broken, as far as the standard goes?

And, strictly speaking, would it be legal for a C compiler to generate
code which pushed a 16-bit value on the stack on a system with 32-bit
integers?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

The Poster did not say, but why assume 32 bits. If he has an 8 bit cpu He should
use the smallest variable possible, especially is RAM is limited. For a 16 bit
X86 still a savings. For a 32 bit cpu most likely no help, and for some maybe
worse.

 

[Villy Kruse]

Emmanuel Delahaye wrote:
[...]

Another point. Defining a parameter as char is pointeless. It will
always be converted to an int and will use an int print in automatic
memory.

Is this strictly true?

No.

If compilers do it anyway (pass char values as int) it can have following
reasons:
- It is easier to keep the stack varables alligned if you pass only
32bit and 64bit items.
- Functions are still callable from old K&R style written programs,
that is, no prototype.
- Similarly, functions written in K&R style can still be called from
programs written using ANSI prototypes.

Villy

 

[Lawrence Kirby]

Thanks a lot! I am cooperating with others.
other people have defined
#define Byte unsigned char

so I have to use it.

So is the following a better way?

A better way for what?

Byte a;
unsigned short tmp;

How is tmp set?

if(tmp>256)
tmp = 0;
tmp ++
a = tmp;

If tmp starts as 255 or 256 and UCHAR_MAX is 255 the final value of tmp
won't fit in a. What is this code supposed to do? In terms of code
efficiency you're probably better off using unsigned int than unsigned
short.

Lawrence

 

[Kenneth Brody]

Kenneth Brody wrote: [...]

void foo(char c)
{
... do stuff with 'c' ...
}

void myfunc(void)
{
foo('a');
}

Assuming 32-bit ints and the ASCII character set, must the compiler
generate code that passes 0x00000061 to foo?

[...]
The Poster did not say, but why assume 32 bits. If he has an 8 bit cpu
He should use the smallest variable possible, especially is RAM is
limited. For a 16 bit X86 still a savings. For a 32 bit cpu most
likely no help, and for some maybe worse.

If I hadn't listed those assumptions, someone would have (rightfully)
pointed out that there are non-32-bit systems, and non-ASCII systems,
where 'a' is not 0x00000061.

Perhaps I should have said "given a system with 32-bit integers and
the ASCII character set..."?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[pete]

A better way for what?


How is tmp set?


If tmp starts as 255 or 256 and
UCHAR_MAX is 255 the final value of tmp
won't fit in a. What is this code supposed to do? In terms of code
efficiency you're probably better off using unsigned int than unsigned
short.

I'm guessing that he wants the count to go up from 0
and then roll over after 255,
but I'm assuming that he's not expressing himself well.

/* BEGIN new.c */

#include <stdio.h>

typedef unsigned char Byte;

int main(void)
{
Byte a;
unsigned count, tmp;

tmp = a = 0;
for (count = 3; count != 0; --count) {
do {
++tmp;
tmp &= 0xff;
a = (Byte)tmp;
if (a == 255) {
printf("%u ", (unsigned)a);
}
if (a == 256) {
printf("%u ", (unsigned)a);
}
} while (a != 0);

}
putchar('\n');
return 0;
}

/* END new.c */

 

[pete]

I'm guessing that he wants the count to go up from 0
and then roll over after 255,
but I'm assuming that he's not expressing himself well.

/* BEGIN new.c */

#include <stdio.h>

typedef unsigned char Byte;

int main(void)
{
Byte a;
unsigned count, tmp;

tmp = a = 0;
for (count = 3; count != 0; --count) {
do {
++tmp;
tmp &= 0xff;
a = (Byte)tmp;

/* I think this way is more better */

++tmp;
a = (Byte)(tmp & 0xff);