char vs. unsigned char

[Steven Jones]

Can anybody illustrate the usefulness of having char and unsigned char? I
mean, under what circumstances would one want to use unsigned char (or
unsigned char *) rather than char (or char *, respectively)?

 

[Keith Thompson]

Can anybody illustrate the usefulness of having char and
unsigned char? I mean, under what circumstances would one want to
use unsigned char (or unsigned char *) rather than char (or char *,
respectively)?

Use plain char (which may be either signed or unsigned) when you want
to represent characters, or when you only care about representing
integer values in the range 0 to 127.

Use signed char when you want a signed integer type that covers values
from -127 to +127 (or more; that's the minimum guaranteed range).

Use unsigned char when you want an unsigned integer type that covers
values from 0 to 255 (or more; that's the minimum guaranteed range),
or when you want to examine the representation of any object. (The
standard guarantees that any object of any type can be treated as an
array of unsigned char.)

 

[Rod Pemberton]

Can anybody illustrate the usefulness of having char and unsigned char? I
mean, under what circumstances would one want to use unsigned char (or
unsigned char *) rather than char (or char *, respectively)?

The use of unsigned char can prevent many problems with OS related function
calls. About the only use I've found for a signed char that can't be done
with an unsigned char or a larger type, is to detect passing through zero by
decrementing.

 

[Michael Mair]

Can anybody illustrate the usefulness of having char and unsigned char? I
mean, under what circumstances would one want to use unsigned char (or
unsigned char *) rather than char (or char *, respectively)?

I assume you know that char and signed char (sic!) are distinct types
with potentially even different signedness.
In the "C that could have been", a character type would not be one
of the ordinary integer types but would have been an unsigned type
(or a type to which the concept of signedness does not apply) and
there would have been a "byte" integer type.
So, we have to deal with what we have got; use unsigned char whenever
you want a "byte" (e.g. for accessing an object's representation) and
char whenever you want a character and char is sufficient and int for
all the rest (you want a single character and char is not sufficient).

Now, the remaining question is when you need int; have a look at the
description of getchar() and the <ctype.h> is...() functions. These
return or receive an int value which is either a char value cast to
unsigned char or the negative value EOF.


Cheers
Michael

 

[Skarmander]

I assume you know that char and signed char (sic!) are distinct types
with potentially even different signedness.
In the "C that could have been", a character type would not be one
of the ordinary integer types but would have been an unsigned type
(or a type to which the concept of signedness does not apply) and
there would have been a "byte" integer type.

Arguably it's one of Java's worst misfeatures that it has a "byte" integer
type which is signed; it forces you to deal with this sign even where this
is irrelevant (that is, practically everywhere, since the most common use
for "byte" is to store signless octets).

I hope that your "C that could have been" solves the issue more elegantly. A
separate "char" type is a good idea, and while a signed 8-bit integer type
may have its uses, calling it "byte" is not a good idea, as is not having an
unsigned 8-bit integer type.

S.

 

[Michael Mair]

Arguably it's one of Java's worst misfeatures that it has a "byte"
integer type which is signed; it forces you to deal with this sign even
where this is irrelevant (that is, practically everywhere, since the
most common use for "byte" is to store signless octets).

I hope that your "C that could have been" solves the issue more
elegantly. A separate "char" type is a good idea, and while a signed
8-bit integer type may have its uses, calling it "byte" is not a good
idea, as is not having an unsigned 8-bit integer type.

Yep; I was aware of that when writing the above.
As I do not want to spend too much time on a language that never
existed and will never be useful, I omitted my thoughts on type
naming. Among other things, there could have been a sensible
tradition of "int...." being signed, "uint...." being unsigned,
and semantic types having "signedness" (if any) according to their
semantics, with optional prepended "s" or "u" where applicable
(e.g. byte, [_no_ sbyte,] size, ssize).
And no "multiple keyword combinations for one type" hell.
Not very well thought-out and not very enthusiastically presented,
I know...


Cheers
Michael

 

[Skarmander]

Yep; I was aware of that when writing the above.

I just wanted to vent about Java's "byte", really, which still irks me every
time I make an excursion into Java land. Didn't mean to drag your comments
into it, but they did leave this open as an alternative, so I wanted to
quash that avenue of thought.

As I do not want to spend too much time on a language that never
existed and will never be useful, I omitted my thoughts on type
naming. Among other things, there could have been a sensible
tradition of "int...." being signed, "uint...." being unsigned,
and semantic types having "signedness" (if any) according to their
semantics, with optional prepended "s" or "u" where applicable
(e.g. byte, [_no_ sbyte,] size, ssize).
And no "multiple keyword combinations for one type" hell.
Not very well thought-out and not very enthusiastically presented,
I know...

I wouldn't go so far as to say that will never exist. C99's <stdint.h> goes
a long way, giving you type names for signed and unsigned integers of at
least or exactly N bits (along with the older size_t, ptrdiff_t, etc.) With
judicious use of typedefs you could probably write portable programs that
use these types alone, and writing a <stdint.h> for platforms that don't
have it is fairly simple. Of course it won't eliminate the trickyness of C's
basic types, but it's something.

S.