16

What's the point of negative ASCII values?

int a = '«'; //a = -85 but as in ASCII table '<<' should be 174
Paul R
  • 208,748
  • 37
  • 389
  • 560
user963241
  • 6,758
  • 19
  • 65
  • 93
  • 15
    ASCII codes only go from 0 - 127. – CB Bailey Jan 14 '11 at 11:15
  • 8
    Note that ASCII is only valid for values in the range 0..127. So-called *extended ASCII* includes values from 128..255 and you are just seeing such a value here expressed as a signed char. – Paul R Jan 14 '11 at 11:15
  • 2
    "So-called extended ASCII" does not exist. Single byte encodings however do. – n0rd Jan 14 '11 at 12:06
  • Neither C++ nor C even assumes ASCII anyway. – MSalters Jan 14 '11 at 12:52
  • 1
    You made a mistake in your question. `a = -85` is incorrect. It should be `a = -82`. This is because the range of the extended ASCII table is 0 - 255 inclusive. That's a total of 256 possible values. For both a positive value and a negative value to be the same symbol (in this case `<<`) they have to be 256 values apart for the symbol to repeat itself. – Wandering Fool May 26 '15 at 23:47

6 Answers6

15

There are no negative ASCII values. ASCII includes definitions for 128 characters. Their indexes are all positive (or zero!).

You're seeing this negative value because the character is from an Extended ASCII set and is too large to fit into the char literal. The value therefore overflows into the bit of your char (signed on your system, apparently) that defines negativeness.

The workaround is to write the value directly:

unsigned char a = 0xAE; // «

I've written it in hexadecimal notation for convention and because I think it looks prettier than 174. :)

Adrian McCarthy
  • 45,555
  • 16
  • 123
  • 175
Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • 1
    Their indexes are all non-negative ;-) . – CB Bailey Jan 14 '11 at 11:19
  • 1
    There is no such thing as "Extended ASCII". – R.. GitHub STOP HELPING ICE Jan 14 '11 at 17:25
  • 2
    @R Of course there is. It's a somewhat-colloquial term describing a few standards, but they all share the properties that are relevant in this question and this answer. http://en.wikipedia.org/wiki/Extended_ASCII – Lightness Races in Orbit Jan 14 '11 at 17:27
  • 1
    Someone should delete the wiki entry. The values associated with 'EXTENDED ASCII' as you call it, vary by platform. Hence they are not standard. Look up the phrase 'CHARACTER SET', and observe that some platforms include ASCII in their character set. – EvilTeach Jan 15 '11 at 02:43
  • @EvilTeach I never said that they are standard. I said "somewhat-colloquial terms". – Lightness Races in Orbit Jan 16 '11 at 15:33
  • 1
    @EvilTeach: Luckily, that's exactly what the Wikipedia page says. "The term extended ASCII (or high ASCII) describes eight-bit or larger character encodings that include the standard seven-bit ASCII characters as well as others. The use of the term is sometimes criticized, because it can be mistakenly interpreted that the ASCII standard has been updated to include more than 128 characters or that the term unambiguously identifies a single encoding, both of which are untrue." – Mooing Duck Nov 12 '12 at 21:10
  • "Basterdized ASCII" – Emile Cormier Feb 15 '20 at 22:27
11

This is an artefact of your compiler's char type being a signed integer type, and int being a wider signed integer type, and thus the character constant is considered a negative number and is sign-extended to the wider integer type.

There is not much sense in it, it just happens. The C standard allows for compiler implementations to choose whether they consider char to be signed or unsigned. Some compilers even have compile time switches to change the default. If you want to make sure about the signedness of the char type, explicitly write signed char or unsigned char, respectively.

Use an unsigned char to be extended to an int to avoid the negative int value, or open a whole new Pandora's box and enjoy wchar.

ndim
  • 35,870
  • 12
  • 47
  • 57
  • 2
    No, it's because the character does not fit in the literal. The problem occurs *before* the `int` even comes into the picture. The literal ends up with the value -85 due to overflow, and then this value -85 is assigned to the int. (It's possible that this is what you meant, and I misunderstood you.) – Lightness Races in Orbit Jan 14 '11 at 11:42
  • @Tomalak: it is just semantics whether unsigned 174 just happens to be signed -85 or whether there was an overflow. For me overflowing has more to do with calculations. In the end, the result is the same. – stefaanv Jan 14 '11 at 12:02
  • @stefaanv: That's fine; it's not what I was contesting. – Lightness Races in Orbit Jan 14 '11 at 12:06
  • 4
    "the character does not fit in the literal". That really makes no sense. Any narrow character fits into a `char`. To make it not fit, you need multiple characters (`int a = 'ab'; /* !! */`). C does not require that characters have positive values. Hence, implementations are free to assign the value -85 to '«' – MSalters Jan 14 '11 at 12:52
3

There is no such thing. ASCII is a table of characters, each character has an index, or a position, in the table. There are no "negative" indices.

Some compilers, though, consider char to be a signed integral data type, which is probably the reason for the confusion here.

If you print it as unsigned int, you will get the same bits interpreted as a unsigned (positive) value.

unwind
  • 391,730
  • 64
  • 469
  • 606
2

ASCII ranges 0..127, ANSI (also called 'extended ASCII') ranges 0..255.

ANSI range won't fit in a signed char (the default type for characters in most compilers).

Most compilers have an option like 'char' Type is Unsigned (GCC).

jv42
  • 8,521
  • 5
  • 40
  • 64
  • 3
    Signed char is not "the default type for characters" at all. The signedness of an unqualified `char` type is completely implementation-specified. Character literals have type `char`. His system just happens to use a signed implementation for `char` (as do the majority of popular systems, I believe). – Lightness Races in Orbit Jan 14 '11 at 11:40
  • (This is contrary to `int`, which is explicitly, always, the same as `signed int`.) – Lightness Races in Orbit Jan 14 '11 at 11:40
  • I will clarify this. I meant 'default in most compilers', not specification. – jv42 Jan 14 '11 at 12:11
  • 1
    Fun fact: Regardless of your implementations signedness of `char`, `char` is a different type from both `signed char` and `unsigned char`. – etarion Jan 14 '11 at 12:21
  • @jv42: OK, then that is largely correct. `char` on most implementations that you find on popular commodity hardware nowadays is a signed type. – Lightness Races in Orbit Jan 14 '11 at 17:29
  • @Lightness Races in Orbit "`int`, which is explicitly, always, the same as signed `int`" --> usually, yet not always: [What is the type of a bitfield?](http://stackoverflow.com/a/13105400/2410359) Of course not in this post's issue. – chux - Reinstate Monica Sep 02 '15 at 21:08
  • @chux: No, `int` is defined to be identical to `signed int`. I'm on holiday so I haven't checked the standard before replying but, then, I don't need to. :) – Lightness Races in Orbit Sep 03 '15 at 01:22
1

I had this artifact. When you use char as symbols you have no problem. But when you use it as integer (with isalpha(), etc.) and the ASCII code is greater then 127, then the 'char' interpret as 'signed char' and isalpha() return an exception. When I need use the 'char' as integer I cast the 'char' to unsigned:

  • isalpha((unsigned char)my_char);

@n0rd: koi8 codepage uses ascii from 128 to 255 and other national codepages: http://www.asciitable.com/

SVGreg
  • 2,320
  • 1
  • 13
  • 17
0

In a character representation, you have 8 bits (1 byte) allotted. Out of this, the first bit is used to represent sign. In the case of unsigned character, it uses all 8 bits to represent a number allowing 0 to 255 where 128-255 are called extended ASCII. Due to the representation in the memory as I have described, we have -1 having the same value as 255, char(-2)==char(254)

ammportal
  • 991
  • 1
  • 11
  • 27
Arjun Gopkumar
  • 3
  • 3