What is the point of signed char?

[pete]

the DS9K, or DeathStar 9000,

Death Station 9000.

 

[Keith Thompson]

Death Station 9000.

I sit corrected. Thank you.

 

[CBFalconer]

...

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 DS9K has been famous in this group for many years. It is
really a thought experiment, to demonstrate what can legitimately
happen when you contravene the standards in any way. Since
absolutely anything goes when UB is invoked, there are some
competitions to imagine results suitable for the particular case.
Somebody ran nonconforming programs on it on November Tuesdays in
2000 and 2004, and look what happened!

Your being Russian has nothing to do with it.

 

[Netocrat]

The DS9K has been famous in this group for many years. It is
really a thought experiment, to demonstrate what can legitimately
happen when you contravene the standards in any way. Since
absolutely anything goes when UB is invoked, there are some
competitions to imagine results suitable for the particular case.
Somebody ran nonconforming programs on it on November Tuesdays in
2000 and 2004, and look what happened!

Your being Russian has nothing to do with it.

Alexei can correct me if I'm wrong, but I believe his complaint was
against Mark's use of the phrase "send signed photos of your bottom to
the patriarch of moscow", which Alexei has interpreted (rightly or
wrongly - only Mark can answer that) as being a reference to Alexei
being Russian. I don't believe he was specifically complaining about
the use of the DS9K thought experiment as an explanation as Keith and
yourself have interpreted him as doing.

 

[Richard Heathfield]

The point is that the DS9K, or DeathStar 9000, is a purely mythical
computer system, invented in this newsgroup and never actually
implemented.

http://dspace.dial.pipex.com/town/green/gfd34/art/

 

[CBFalconer]

.... snip ...

Alexei can correct me if I'm wrong, but I believe his complaint was
against Mark's use of the phrase "send signed photos of your bottom to
the patriarch of moscow", which Alexei has interpreted (rightly or
wrongly - only Mark can answer that) as being a reference to Alexei
being Russian. I don't believe he was specifically complaining about
the use of the DS9K thought experiment as an explanation as Keith and
yourself have interpreted him as doing.

And I interpret Marks effort as an attempt to describe something
that would appear totally ridiculous to a Russian eye. Mark is not
especially noted for subtle diplomacy, nor for any evil attitudes.
I also think Alexei is not too sure how to treat the collection of
nuts who are congregating in this thread.

 

[Chris Hills]

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.

So what about 8 bit MCU? these are very widely used. You don't want to
use a 16 bit int with these if possible.

 

[ng5000]

Thanks for all your thoughts and comments. I now believe the following
to be true:

A signed char should only be used where C99 is not available and
space is a consideration.

Nick

 

[Richard Heathfield]

Thanks for all your thoughts and comments. I now believe the following
to be true:

A signed char should only be used where C99 is not available and
space is a consideration.

That seems like a reasonable summary. In practice, you'll probably never
need one. Certainly not on the "desktop", anyway.

 

[Lawrence Kirby]

Thanks for all your thoughts and comments. I now believe the following
to be true:

A signed char should only be used where C99 is not available and
space is a consideration.

A signed char is a reasonable choice when you want to hold a value between
-127 and 127, or -128 if you accept a little non-portability.

Lawrence

 

[ng5000]

That seems like a reasonable summary. In practice, you'll probably never
need one. Certainly not on the "desktop", anyway.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
mail: rjh at above domain

The funny thing is we're an embedded systems company. All our C is 'in
the box'. We use C#, Borland, etc. for most of our desktop
development.

In the past we've always used chars as a kind of 'byte' type in or
code. We got cought out recently though when we ported some old C to a
new development. The new hardware platform's compiler defaulted chars
to signed chars. Because the code expected char to be unsigned lots of
problems started to occur (I know one shouldn't expect a char to be
unsigned, but that's the way it was).

That set me thinking about chars and signedness and what the purpose of
signed chars was post C99. The only time I ever think they would be
useful is on a non 8 bit system (say 5 bit or 13 bit), where an int
would be too small or too big.

Nick

 

[Lawrence Kirby]

On Tue, 19 Jul 2005 05:10:55 -0700, ng5000 wrote:

....

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

As others have said character types are simply integer types, you could
think of them as simply a (possibly) shorter integer type than short. That
means that "characters" are nothing more than integer values that fit in a
char type.

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

If int8_t exists then char must be an 8 bit type on that system. It is
very likely that where it exists int8_t will be typedef'd as char or
signed char. char is the smallest type in C, int8_t can never be smaller.
Or to put it another way if char is not 8 bits wide then int8_t cannot
exist on that implementation.

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

You don't even have a guarantee with stdint.h. You are guaranteed that if
int8_t exists it is 8 bits wide with a 2's complement representation, but
you are not guaranteed that it exists.

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

int is often used for characters, just look at the return type of
getchar() and argument type of putchar() for example. char is a small
integer type and it is perfectly reasonable to use it as such if that is
what you need.

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?

signed char is typically used to hold numbers rather than specifically
character values. The oddity is that plain char can be and often is
implemented as signed. That's just one of the historical quirks of C, the
language would be a lot cleaner if it was always unsigned.

Lawrence

 

[Chris Dollin]

That set me thinking about chars and signedness and what the purpose of
signed chars was post C99. The only time I ever think they would be
useful is on a non 8 bit system (say 5 bit or 13 bit), where an int
would be too small or too big.

If an int is too small, a char would be too small also.

[And as far as C is concerned, a 5-bit system is likely to be
a 10-bit system.]

[Are 12-bit systems still in wide use?]

 

[Peter Nilsson]

If int8_t exists then char must be an 8 bit type on that system. It
is very likely that where it exists int8_t will be typedef'd as char
or signed char. ...

I don't think that int8_t can be typedef'd as (plain) char in the
strictest sense. C99 states that "int8_t denotes a signed integer
type...", however plain char is not a signed integer type (per
6.2.5p4).

That said, the 'as if' rule applies!

 

[Alexei A. Frounze]

That set me thinking about chars and signedness and what the purpose of
signed chars was post C99. The only time I ever think they would be
useful is on a non 8 bit system (say 5 bit or 13 bit), where an int
would be too small or too big.

If an int is too small, a char would be too small also.

[And as far as C is concerned, a 5-bit system is likely to be
a 10-bit system.]

[Are 12-bit systems still in wide use?]

I know of 16-bit ones (char=short=int=16 bits, long=32 bits, long long=40
bits).

Alex

 

[Gordon Burditt]

[Are 12-bit systems still in wide use?]

I know of 16-bit ones (char=short=int=16 bits, long=32 bits, long long=40
bits).

That's rather strange. The number of bits in a long long isn't
a multiple of the number of bits in a char? I suppose C can handle this,
with sizeof(long long) == 3, and long long having 8 padding bits, but
it's rather unusual. Are you sure you didn't mean long long = 48 bits?
What's the alignment requirement for long long? 2.5?

Gordon L. Burditt

 

[Clark S. Cox III]

That set me thinking about chars and signedness and what the purpose of
signed chars was post C99. The only time I ever think they would be
useful is on a non 8 bit system (say 5 bit or 13 bit), where an int
would be too small or too big.

If an int is too small, a char would be too small also.

[And as far as C is concerned, a 5-bit system is likely to be
a 10-bit system.]

[Are 12-bit systems still in wide use?]

I know of 16-bit ones (char=short=int=16 bits, long=32 bits, long long=40
bits).

Then that's a non-conforming implementation (long long is too small).

 

[Keith Thompson]

signed char is typically used to hold numbers rather than specifically
character values. The oddity is that plain char can be and often is
implemented as signed. That's just one of the historical quirks of C, the
language would be a lot cleaner if it was always unsigned.

IMHO, the language would be cleaner if it had a "byte" type that's
just another integer type (signed by default like any other integer
type; use "unsigned byte" if you want an unsigned byte), and a
separate "char" type whose signedness is irrelevant. But of course
it's to late to fix that.

 

[Keith Thompson]

I don't think that int8_t can be typedef'd as (plain) char in the
strictest sense. C99 states that "int8_t denotes a signed integer
type...", however plain char is not a signed integer type (per
6.2.5p4).

That said, the 'as if' rule applies!

If you're correct that int8_t can't be typedef'ed as plain char, the
"as if" rule doesn't apply. The following would be illegal:

int8_t *iptr;
unsigned char *cptr;
cptr = iptr;

 

[Alexei A. Frounze]

[Are 12-bit systems still in wide use?]

I know of 16-bit ones (char=short=int=16 bits, long=32 bits, long long=40
bits).

That's rather strange. The number of bits in a long long isn't
a multiple of the number of bits in a char? I suppose C can handle this,
with sizeof(long long) == 3, and long long having 8 padding bits, but
it's rather unusual.

Exactly this way.

Are you sure you didn't mean long long = 48 bits?

Nope, just 40 are usable.

What's the alignment requirement for long long? 2.5?

Should be 2, can't be a half. I've never tried using this long long type in
C, though, only in ASM. But the compiler claims to be supporting this type.

It's TI's DSP C5xxx series. An accumulator there is 40 bits long, out of
which the top 8 are used as guard bits for filter output calculation using
some MAC (multiply and accumulate) instruction. MACs multiply two 16-bit
integers and add them to the accumulator. Exactly as many repetitions of MAC
are needed as the filter's length. Hence, the top 8 bits are very handy as
they allow to keep the intermediate sum in 40 bits and avoid unwanted
rounding too early (actually, not too early but on each instruction).

Alex