What is the point of signed char?

[ng5000]

Hi,

What's the point of a signed char? As I see it a char represents a
character (not an integer, use an int type e.g. short int if you want
an 8 bit number, or one of the new types, uint8 I think).

I don't know of any character sets that use negatives, e.g. 65 is 'A'
and -65 is 'a'?!?

I'm sure I'm missing something, any ideas?

Also, am I right in saying that the current standards state that
whether a char is signed or unsigned is implementation dependent?

Nick

 

[junky_fellow]

Hi,

What's the point of a signed char? As I see it a char represents a
character (not an integer, use an int type e.g. short int if you want
an 8 bit number, or one of the new types, uint8 I think).

I don't know of any character sets that use negatives, e.g. 65 is 'A'
and -65 is 'a'?!?

I'm sure I'm missing something, any ideas?

Also, am I right in saying that the current standards state that
whether a char is signed or unsigned is implementation dependent?

Nick

If you have some integer variable that could have values in between
-127 to 127, then you can use signed char to save space.

 

[ng5000]

If you have some integer variable that could have values in between
-127 to 127, then you can use signed char to save space.

Buf if I'm storing an integer then surly it would be better to use an
integer type? If I'm worried about space then I could use int8_t (from
C99 stdint.h). As I understand it unless I use the stdint.h types I
have no guarantee over size, not even for a char.

Am I not right in suggesting that 'char' should be used for characters
and 'int' should be used for integers? If I am right then what is the
point of a signed char when no character set that I'm aware of uses
negative numbers?

 

[Richard Bos]

Buf if I'm storing an integer then surly it would be better to use an
integer type?

All three char types _are_ integer types.

If I'm worried about space then I could use int8_t (from
C99 stdint.h).

If you have C99, yes. If your implementation has an 8 bit type, yes. If
you just want the guaranteed smallest integer type, you can always use
char.

Yes, it would've been better if there had been two separate sets of
types, char and byte. But this is how it has grown to be.

Richard

 

[Chris Dollin]

Buf if I'm storing an integer then surly it would be better to use an
integer type?

char (and signed char, and unsigned char) *are* integer types.

If I'm worried about space then I could use int8_t (from
C99 stdint.h).

If you're using C99, yes. [I don't think it's possible for an int8_t
to be smaller than a char, though.]

As I understand it unless I use the stdint.h types I
have no guarantee over size, not even for a char.

You're guaranteed that `char` is the smallest type. You're guaranteed
that it can hold at least 8 bits, so it's certainly got a range of
0..127.

Am I not right in suggesting that 'char' should be used for characters
and 'int' should be used for integers?

You are not right.

Use `char` for characters, and *if you need the space*, for small
enough integers. Use `signed char` and `unsigned char` if you need
to be specific about signedness.

Use `short` for integers that are short enough, if you need the
space.

Use `int` for integers, unless you need `long [long]` integers,
or something still bigger.

 

[ng5000]

You're guaranteed that `char` is the smallest type. You're guaranteed
that it can hold at least 8 bits, so it's certainly got a range of
0..127.

If that is the case how does the C standard work for non 8 bit
platforms? (can't think of any, but for discussion purposes say a 5 bit
system).

Am I not right in suggesting that 'char' should be used for characters
and 'int' should be used for integers?

You are not right.

Use `char` for characters, and *if you need the space*, for small
enough integers. Use `signed char` and `unsigned char` if you need
to be specific about signedness.

Use `short` for integers that are short enough, if you need the
space.

Use `int` for integers, unless you need `long [long]` integers,
or something still bigger.

So, as I understand it I can take a char to be the smallest possible
data type, regardless of implementation? So, on a 5 bit system a char
would be 5 bits, on an 8 bit 8 bits etc.?

Would you agree that my assertion to use 'char' for characters is
correct when programming with C99?

 

[Chris Dollin]

If that is the case how does the C standard work for non 8 bit
platforms? (can't think of any, but for discussion purposes say a 5 bit
system).

The implementor will have work to do. EG implement C chars as
two five-bit charlets.

So, as I understand it I can take a char to be the smallest possible
data type, regardless of implementation? So, on a 5 bit system a char
would be 5 bits, on an 8 bit 8 bits etc.?

No; char is the /smallest available C type/ [1] in a C implementation.
Nothing stops an implementor having 16-bit characters, even on a
machine with an 8-bit implementation type.

Would you agree that my assertion to use 'char' for characters is
correct when programming with C99?

If you're content with the restriction to 8 bits. Some people
are not; hence wide characters and other games.

[1] Not counting bitfields.

 

[Chris Croughton]

If that is the case how does the C standard work for non 8 bit
platforms? (can't think of any, but for discussion purposes say a 5 bit
system).

C insists that char is at least 8 bits, so on a system where the
smallest addressable unit is less than that it would have to be emulated
(as two 'nybbles' or whatever).

If the size of the smallest addressable unit is more than 8 bits that
can be used as a char, so there are systems on which char is 9, 12, 16,
24 and 32 bits in size (at least, there are probably other sizes as
well). Some, however, may generate special code to subdivide the
natural units (for instance a machine which addresses memory as 32 bit
words may explicitly do masking to address 8 bit chars).

So, as I understand it I can take a char to be the smallest possible
data type, regardless of implementation? So, on a 5 bit system a char
would be 5 bits, on an 8 bit 8 bits etc.?

On a 5 bit system a char would probably be 10 bits, because 5 bits is
not allowed.

Would you agree that my assertion to use 'char' for characters is
correct when programming with C99?

A char is the smallest type in which the entire required character set
can be represented. That's the character set required by the standard,
which may be much smaller than the character set supported by the
program (for instance, it misses out characters like @ and backquote and
lots of the 'control' characters). For ASCII 7 bits suffices, for
EBCDIC 8 bits.

Chris C

 

[ng5000]

C insists that char is at least 8 bits, so on a system where the
smallest addressable unit is less than that it would have to be emulated
(as two 'nybbles' or whatever).

If the size of the smallest addressable unit is more than 8 bits that
can be used as a char, so there are systems on which char is 9, 12, 16,
24 and 32 bits in size (at least, there are probably other sizes as
well). Some, however, may generate special code to subdivide the
natural units (for instance a machine which addresses memory as 32 bit
words may explicitly do masking to address 8 bit chars).


On a 5 bit system a char would probably be 10 bits, because 5 bits is
not allowed.


A char is the smallest type in which the entire required character set
can be represented. That's the character set required by the standard,
which may be much smaller than the character set supported by the
program (for instance, it misses out characters like @ and backquote and
lots of the 'control' characters). For ASCII 7 bits suffices, for
EBCDIC 8 bits.

Chris C

Hi Chris,

Given 'entire required character set', am I to take it the standard
specifies a character set, or would the implementor be able to
implement any character set they wanted, even bespoke if required?

Thanks

Nick

 

[Clark S. Cox III]

Hi Chris,

Given 'entire required character set', am I to take it the standard
specifies a character set,

There is a minimum character set that must be representable. This set
includes all of the latin letters, the decimal digits, 29 graphical
characters (parenthesis, quotes, semicolons, etc), as well as some tab,
space and end of line characters.

or would the implementor be able to
implement any character set they wanted, even bespoke if required?

As long as the set they choose is a superset of the basic execution
character set, yes.

 

[Richard Bos]

(e-mail address removed) wrote:

[ Snip! ]

Given 'entire required character set', am I to take it the standard
specifies a character set, or would the implementor be able to
implement any character set they wanted, even bespoke if required?

The Standard requires that both source and execution character sets
(basically, the set your compiler uses and the set the resulting program
uses, which may be different, e.g. for a cross-compiler) have a certain
minimum set of members. For example, all character sets must have both
upper and lower case a-z; 0-9; and some punctuation and control
characters. All members of this basic set must be positive, except the
string terminating null character, which must have value zero. All must
fit in a byte (not necessarily 8-bit), and therefore in a char. 0 to 9
must be subsequent and ascending.

If your bespoke character set complies with these demands, it can be
used for a C implementation. All signed and unsigned ASCII extensions,
including Unicode, do. So does unsigned EBCDIC.

Richard

 

[ng5000]

Thanks all.

 

[Malcolm]

What's the point of a signed char?

Not much. It can be used as an integer between -128 and 127. However almost
always you are better off with a plain int or, if memory is at a premium,
with a bitfield.

If a char holds a character it should be plain char. If it holds arbitrary
binary data, it should be an unsigned char. unsigned chars may not have trap
representations, which is why such data should never be plain char or signed
char.

 

[Jack Klein]

Not much. It can be used as an integer between -128 and 127. However almost

^^^^^^^^^^^^
-127 and +127. -128 is neither required nor guaranteed, and is not
available on 1's complement or signed magnitude representations. It
is not even provided on all 8-bit 2's complement implementations.

 

[Alexei A. Frounze]

almost
^^^^^^^^^^^^
-127 and +127. -128 is neither required nor guaranteed, and is not
available on 1's complement or signed magnitude representations. It
is not even provided on all 8-bit 2's complement implementations.

While I would certainly agree with the absence of -128 on hardware employing
1's complemented and signed magnitude integer formats, I don't quite
understand what should impose the same limit on the 2's compelemted one?

Alex

 

[CBFalconer]

While I would certainly agree with the absence of -128 on hardware
employing 1's complemented and signed magnitude integer formats, I
don't quite understand what should impose the same limit on the 2's
compelemted one?

The lack of any contrary requirement in the standard. This makes
it possible to treat the signed char value 0x80 as a trap value in
a 2's comp. system, for example. That trap has to be shut off for
an unsigned char.

The only current system to implement this is the DeathStation 9000.

 

[Alexei A. Frounze]

The lack of any contrary requirement in the standard. This makes
it possible to treat the signed char value 0x80 as a trap value in
a 2's comp. system, for example. That trap has to be shut off for
an unsigned char.

The only current system to implement this is the DeathStation 9000.

You mean it supports "symmetrical" 2's complemented?
The thing is, to take that -128/0x80 out, extra circuitry/work is needed,
while to keep it there, nothing needs to be done. I expect that not many are
going to do this work...

Alex

 

[Mark McIntyre]

news:[email protected]...

(of not allowing -128 for signed chars)

You mean it supports "symmetrical" 2's complemented?

The DS9K is animplementation that frowns severely on straying outside
the Standard. If the standard doesn't require signed char to include
-128, you can bet your bottom dollar that using it on the DS9K will
invoke a nuclear strike on mars or send signed photos of your bottom
to the patriarch of moscow. Or both.

The thing is, to take that -128/0x80 out, extra circuitry/work is needed,

The designers of the DS9K left no stone unturned and no extra
circuitry unimplemented. They worked day and night, and some of the
other time too, in order to bring you the finest, most lethal UB you
can imagine.

For more details, see the bloopers section of this website
http://dspace.dial.pipex.com/town/green/gfd34/art/

 

[Alexei A. Frounze]

On Wed, 20 Jul 2005 14:11:01 +0400, in comp.lang.c , "Alexei A.


The DS9K is animplementation that frowns severely on straying outside
the Standard. If the standard doesn't require signed char to include
-128, you can bet your bottom dollar that using it on the DS9K will
invoke a nuclear strike on mars or send signed photos of your bottom
to the patriarch of moscow. Or both.

....

Guys, is it absolutely required to respond like this? And what's funny or
bad in that I'm a Russian? What have I done to you to read this now?
Why do I get such a response in this group 2nd time this week?

Alex

 

[Keith Thompson]

...

Guys, is it absolutely required to respond like this? And what's funny or
bad in that I'm a Russian? What have I done to you to read this now?
Why do I get such a response in this group 2nd time this week?

The point is that the DS9K, or DeathStar 9000, is a purely mythical
computer system, invented in this newsgroup and never actually
implemented. It has a C implementation that strictly conforms to the
ISO C standard, but that behaves as perversely as possible whenever
it's allowed to do so. If your program invokes undefined behavior by
writing beyond the end of an array, a real-world system might respond
by harmlessly modifying unallocated memory, or by modifying another
nearby variable, or by causing your program to die with a segmentation
fault. The DS9K is more likely to teleport your lunch to the center
of the Sun, or transform your left ear into a small elephant --
behaviors that are equally valid as far as the standard is concerned.

We use the DS9K to illustrate the fact that the C standard
specifically imposes no requirements on undefined behavior. The
actual symptoms are deliberately made as silly as possible to
emphasize the point. (And we don't usually explain the joke.)

I can't speak for Mark, but I don't believe he intended to insult you
for being Russian. He simply chose an example that was deliberately
as absurd as possible.