469,903 Members | 1,918 Online

# What is the point of signed char?

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

Nov 15 '05 #1
64 4061

ng****@gmail.com wrote:
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.

Nov 15 '05 #2

ju**********@yahoo.co.in wrote:
ng****@gmail.com wrote:
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.

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?

Nov 15 '05 #3
ng****@gmail.com wrote:
ju**********@yahoo.co.in wrote:
ng****@gmail.com wrote:
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).
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?

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
Nov 15 '05 #4
ng****@gmail.com wrote:
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

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.

--
Chris "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.
Nov 15 '05 #5
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

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?

Nov 15 '05 #6
ng****@gmail.com wrote:
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).

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 "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.
Nov 15 '05 #7
On 19 Jul 2005 06:39:18 -0700, ng****@gmail.com
<ng****@gmail.com> wrote:
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).

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
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
Nov 15 '05 #8

Chris Croughton wrote:
On 19 Jul 2005 06:39:18 -0700, ng****@gmail.com
<ng****@gmail.com> wrote:
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).

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
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

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

Nov 15 '05 #9
ng****@gmail.com wrote:

[ Snip! ]
Chris Croughton wrote:
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.

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
Nov 15 '05 #10
On 2005-07-19 11:17:55 -0400, ng****@gmail.com said:

Chris Croughton wrote:
On 19 Jul 2005 06:39:18 -0700, ng****@gmail.com
<ng****@gmail.com> wrote:

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,

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.

--
Clark S. Cox, III
cl*******@gmail.com

Nov 15 '05 #11
Thanks all.

Nov 15 '05 #12

<ng****@gmail.com> wrote
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.
Nov 15 '05 #13
On Tue, 19 Jul 2005 18:44:51 +0000 (UTC), "Malcolm"
<re*******@btinternet.com> wrote in comp.lang.c:

<ng****@gmail.com> wrote
What's the point of a signed char?

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 15 '05 #14
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:ac********************************@4ax.com...
On Tue, 19 Jul 2005 18:44:51 +0000 (UTC), "Malcolm"
<re*******@btinternet.com> wrote in comp.lang.c:

<ng****@gmail.com> wrote
What's the point of a signed char?
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.

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
Nov 15 '05 #15
"Alexei A. Frounze" wrote:
"Jack Klein" <ja*******@spamcop.net> wrote in message
"Malcolm" <re*******@btinternet.com> wrote in comp.lang.c:
<ng****@gmail.com> wrote

What's the point of a signed char?

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

^^^^^^^^^^^^
-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?

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.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
Nov 15 '05 #16
"CBFalconer" <cb********@yahoo.com> wrote in message
news:42***************@yahoo.com...
"Alexei A. Frounze" wrote:
"Jack Klein" <ja*******@spamcop.net> wrote in message
"Malcolm" <re*******@btinternet.com> wrote in comp.lang.c:
<ng****@gmail.com> wrote

> What's the point of a signed char?

Not much. It can be used as an integer between -128 and 127.
^^^^^^^^^^^^
-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?

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
Nov 15 '05 #17
On Wed, 20 Jul 2005 14:11:01 +0400, in comp.lang.c , "Alexei A.
Frounze" <al*****@chat.ru> wrote:
"CBFalconer" <cb********@yahoo.com> wrote in message
news:42***************@yahoo.com...
(of not allowing -128 for signed chars)

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

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/
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 15 '05 #18
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:48********************************@4ax.com...
On Wed, 20 Jul 2005 14:11:01 +0400, in comp.lang.c , "Alexei A.
Frounze" <al*****@chat.ru> wrote:

....
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.

....

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
Nov 15 '05 #19
"Alexei A. Frounze" <al*****@chat.ru> writes:
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:48********************************@4ax.com...
On Wed, 20 Jul 2005 14:11:01 +0400, in comp.lang.c , "Alexei A.
Frounze" <al*****@chat.ru> wrote:

...
>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.

...

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #20
Keith Thompson wrote:
the DS9K, or DeathStar 9000,

Death Station 9000.

--
pete
Nov 15 '05 #21
pete <pf*****@mindspring.com> writes:
Keith Thompson wrote:
the DS9K, or DeathStar 9000,

Death Station 9000.

I sit corrected. Thank you.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #22
"Alexei A. Frounze" wrote:
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
"Alexei A. Frounze" <al*****@chat.ru> wrote:

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

The DS9K is an implementation 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?

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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
Nov 15 '05 #23
On Thu, 21 Jul 2005 02:03:31 +0000, CBFalconer wrote:
"Alexei A. Frounze" wrote:
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
"Alexei A. Frounze" <al*****@chat.ru> wrote:

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

The DS9K is an implementation 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?

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.

Nov 15 '05 #24
Keith Thompson wrote:
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/

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
mail: rjh at above domain
Nov 15 '05 #25
Netocrat wrote:
.... 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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.

Nov 15 '05 #26
In article <db**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>, Malcolm
<re*******@btinternet.com> writes

<ng****@gmail.com> wrote
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.

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.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #27
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

Nov 15 '05 #28
ng****@gmail.com wrote:
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
mail: rjh at above domain
Nov 15 '05 #29
On Thu, 21 Jul 2005 02:19:03 -0700, ng5000 wrote:
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
Nov 15 '05 #30
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

Nov 15 '05 #31

Richard Heathfield wrote:
ng****@gmail.com wrote:
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.

--
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

Nov 15 '05 #32
ng****@gmail.com wrote:
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?]

--
Chris "fond memories of the PDP-8" Dollin
It's called *extreme* programming, not *stupid* programming.
Nov 15 '05 #33
Lawrence Kirby wrote:
On Tue, 19 Jul 2005 05:10:55 -0700, ng5000 wrote:
...
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. ...

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!

--
Peter

Nov 15 '05 #34
"Chris Dollin" <ke**@hpl.hp.com> wrote in message
news:db**********@malatesta.hpl.hp.com...
ng****@gmail.com wrote:
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
Nov 15 '05 #35
>> [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
Nov 15 '05 #36
On 2005-07-21 13:29:47 -0400, "Alexei A. Frounze" <al*****@chat.ru> said:
"Chris Dollin" <ke**@hpl.hp.com> wrote in message
news:db**********@malatesta.hpl.hp.com...
ng****@gmail.com wrote:
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).

--
Clark S. Cox, III
cl*******@gmail.com

Nov 15 '05 #37
Lawrence Kirby <lk****@netactive.co.uk> writes:
[...]
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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #38
"Peter Nilsson" <ai***@acay.com.au> writes:
Lawrence Kirby wrote:
On Tue, 19 Jul 2005 05:10:55 -0700, ng5000 wrote:
> ...
> 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. ...

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;

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #39
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:11*************@corp.supernews.com...
[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
Nov 15 '05 #40
"Clark S. Cox III" <cl*******@gmail.com> wrote in message
news:2005072114242875249%clarkcox3@gmailcom...
On 2005-07-21 13:29:47 -0400, "Alexei A. Frounze" <al*****@chat.ru> said:
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).

Really? You mean the standard says long long is at least 64 bits? Well, even
if that's true, TI's compiler seems to be not only not conforming to the new
standard, but also having bugs in different places. They do great chips, but
their development tools suck.

Alex
Nov 15 '05 #41
"Alexei A. Frounze" <al*****@chat.ru> writes:
"Clark S. Cox III" <cl*******@gmail.com> wrote in message
news:2005072114242875249%clarkcox3@gmailcom...
On 2005-07-21 13:29:47 -0400, "Alexei A. Frounze" <al*****@chat.ru> said:
> 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).

Really? You mean the standard says long long is at least 64 bits?

Yes. More precisely, the C99 standard requires the range of long long
to be at least -9223372036854775807 .. +9223372036854775807
(-2**63+1 .. 2**63-1).

But perhaps the compiler is a C90 compiler that supports long long as
an extension. If so, it doesn't fail to conform to the C90 standard,
at least for that reason.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #42
On Thu, 21 Jul 2005 02:31:25 +0400, in comp.lang.c , "Alexei A.
Frounze" <al*****@chat.ru> wrote:
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:48********************************@4ax.com.. .
On Wed, 20 Jul 2005 14:11:01 +0400, in comp.lang.c , "Alexei A.
Frounze" <al*****@chat.ru> wrote:...
>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.

...

Guys, is it absolutely required to respond like this?

like what?
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?

You need to get a sense of humour. You also need to follow the link I
posted, and read all about the stuff that ART produce. Or rather, that
someone decided on the 1st of April many years ago, to pretend they
produced.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 15 '05 #43
On 20 Jul 2005 20:30:50 -0700, in comp.lang.c , "Netocrat"
<ne******@dodo.com.au> wrote:
On Thu, 21 Jul 2005 02:03:31 +0000, CBFalconer wrote:
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 as being a reference to Alexei
being Russian.
Certainly it was. I picked something that would be patently absurd to
Alexei. If it'd been a USAnian, I'd have suggested awarding a spoken
english degree to George W.
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.

Myself I think he just has an underdeveloped sense of humour, perhaps
because he's not been in CLC long enough, or because his english
skills are not good enough yet to spot the jokes.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 15 '05 #44
In article <db**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <so************@not.even.this.one.invalid> wrote:
http://dspace.dial.pipex.com/town/green/gfd34/art/

I'm still waiting for my signed photo of Kaz.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
[S]ome models of the DS9000 use an eleven-bit byte, and ... those eleven bits
occupy all but one of the vertices of a regular dodecahedron (the twelfth
vertex is reserved for future expansion). --Eric Sosman in comp.lang.c
Nov 15 '05 #45
Keith Thompson wrote:
"Peter Nilsson" <ai***@acay.com.au> writes:
Lawrence Kirby wrote:
On Tue, 19 Jul 2005 05:10:55 -0700, ng5000 wrote:
> ...
> 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. ...

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;

I'm not sure what you're demonstrating here. The code potentially
violates a constraint on any implementation, irrespective of whether
int8_t can be plain char or not.

AFAICS, implementations are allowed to make int8_t an exteneded integer
type. Consider an implementation where signed char is not 2c, but the
implementation can mimic a signed 2c octet integer.

But whether it's int8_t, size_t, time_t, etc..., no strictly
conforming C99 program can determine _which_ typedef was invoked.

That's the point I was making. The standard doesn't appear to allow
int8_t to be typedef-ed as a plain char, but the only way to check
it is by looking at the implementation source code (if any), which
is irrelevant.

--
Peter

Nov 15 '05 #46
"Peter Nilsson" <ai***@acay.com.au> writes:
Keith Thompson wrote:
"Peter Nilsson" <ai***@acay.com.au> writes:
> Lawrence Kirby wrote:
>> On Tue, 19 Jul 2005 05:10:55 -0700, ng5000 wrote:
>> > ...
>> > 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. ...
>
> 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;

I'm not sure what you're demonstrating here. The code potentially
violates a constraint on any implementation, irrespective of whether
int8_t can be plain char or not.

You're right, I was being a bit sloppy. The point, I guess, is that
the above code fragment violates a constraint on any possible
conforming implementation. If an implementation chose to take
advantage of the "as if" rule, as Lawrence Kirby suggested, the lack
of a diagnostic would demonstrate that the implementation is
non-conforming.
AFAICS, implementations are allowed to make int8_t an exteneded integer
type. Consider an implementation where signed char is not 2c, but the
implementation can mimic a signed 2c octet integer.

But whether it's int8_t, size_t, time_t, etc..., no strictly
conforming C99 program can determine _which_ typedef was invoked.

That's the point I was making. The standard doesn't appear to allow
int8_t to be typedef-ed as a plain char, but the only way to check
it is by looking at the implementation source code (if any), which
is irrelevant.

Agreed, *except* that you can detect the non-conformance by the lack
of a diagnostic.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #47
Mark McIntyre wrote:
On 20 Jul 2005 20:30:50 -0700, in comp.lang.c , "Netocrat"
<ne******@dodo.com.au> wrote:
On Thu, 21 Jul 2005 02:03:31 +0000, CBFalconer wrote:
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 as being a reference to Alexei
being Russian.

Certainly it was. I picked something that would be patently absurd to
Alexei. If it'd been a USAnian, I'd have suggested awarding a spoken
english degree to George W.

you quoted.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
Nov 15 '05 #48
Mark McIntyre wrote:
On 20 Jul 2005 20:30:50 -0700, in comp.lang.c , "Netocrat"
<ne******@dodo.com.au> wrote:
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 as being a reference
to Alexei being Russian.
Certainly it was. I picked something that would be patently absurd to
Alexei. If it'd been a USAnian, I'd have suggested awarding a spoken
english degree to George W.
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.

Correction: on rereading his post I found that Keith's interpretation
was the same as mine.
Myself I think he just has an underdeveloped sense of humour, perhaps
because he's not been in CLC long enough, or because his english
skills are not good enough yet to spot the jokes.

"Look, I'm here to apply for the job of elephant handler - what the
hell relevance does being a midget have to do with my ability to do the
job?"

"When are they gonna stop calling me 'the new kid'?"

You obviously intended it to be taken as a joke put into a personalised
context rather than to provoke such feelings as the above (and my
examples are extreme cases not directly comparable to your joke), but
Alexei's response, particularly considering that he had earlier been
deliberately and unequivocally insulted using his Russian nationality
as part of the insult, does not necessarily stem from a lacking sense
of humour/english skill either.

Nov 15 '05 #49
Nilsson <ai***@acay.com.au> writes
Lawrence Kirby wrote:
On Tue, 19 Jul 2005 05:10:55 -0700, ng5000 wrote:
> ...
> 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. ...

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!

MISRA-C (6.3) has

int8_t
uint8_t
char_t

as plain char is implementation defined.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #50

### This discussion thread is closed

Replies have been disabled for this discussion.