wrong/right ASCII?

When I execute the following code:

Code:

---

#include <stdio.h>

int main()
  {
  char x='ä';  //please note that this is not alphabet 'a'
  int y=(unsigned char)x;
  printf("%d",y);
  return 0;
  }

---

I get the output as 228.
But the output should be '132' which corresponds to that extended
ascii character according to http://www.asciitable.com/
Why do i get this and what am i missing here?
Thanks in advance.

132 is correct, yes. Perhaps you are seeing the wonders of signedness! behold!

Check this out.

Example 1:

Code:

---

#include <stdio.h>

int main()
  {
  unsigned char x='&#228;';  //please note that this is not alphabet 'a'
  int y=(unsigned char)x;
  printf("&#37;d",y);
  return 0;
  }

---

Example 2:

Code:

---

#include <stdio.h>

int main()
  {
  char x='&#228;';  //please note that this is not alphabet 'a'
  int y= 255 + x;
  printf("%d",y);
  return 0;
  }

---

Well,your first example gives the same output 228.
Second one shows 227 because the value of signed character corresponding to 'ä' is -28.
But shouldn't your first one output 132.(This is what i am not getting)
Thanks for your quick reply.

According to my character map, ä is U+00E4, which means I typed that character into this little textbox with Alt-0228. Coincidence?

I suggest you avoid swedish charters in chars, because they are not very good for that.
To use international characters, you really should be using unicode or wide chars.

Quote:

---

According to my character map, ä is U+00E4, which means I typed that character into this little textbox with Alt-0228. Coincidence?

---

Yeah i get it too.
The listing on www.asciitable.com is wrongly ordered then?

Quote:

---

I suggest you avoid swedish charters in chars, because they are not very good for that.
To use international characters, you really should be using unicode or wide chars.

---

:-)I was just experimenting with extended ASCII characters.
Thanks both of you.

What makes you think your system uses extended ASCII? In latin1, 'ä' is 228. But why are you worried about the code for the character in the first place?

Quote:

---

Originally Posted by OnionKnight

What makes you think your system uses extended ASCII? In latin1, 'ä' is 228. But why are you worried about the code for the character in the first place?

---

You are right.
It must be using something else.
Stupid me,that thought never crossed my feeble mind. :p
Thanks OnionKnight.

Quote:

---

Originally Posted by stevesmithx

When I execute the following code:

Code:

---

#include <stdio.h>

int main()
  {
  char x='ä';  //please note that this is not alphabet 'a'
  int y=(unsigned char)x;
  printf("%d",y);
  return 0;
  }

---

I get the output as 228.
But the output should be '132' which corresponds to that extended
ascii character according to http://www.asciitable.com/
Why do i get this and what am i missing here?
Thanks in advance.

---

What you're missing is that there is no such ASCII character. The character set you need, by definition, is not "ASCII" but this "Extended ASCII" thing you refer to in your link. There is no guarantee that your terminal is using this character set, or for that matter your text editor either.

One day I plan to sit down and write up a FAQ about wide characters, character sets, and encodings because this stuff is more complicated than it first appears. As evidenced by questions like "How do I print this extended ASCII character" when there is in fact no such thing as "extended ASCII."

Quote:

---

Originally Posted by brewbuck

What you're missing is that there is no such ASCII character. The character set you need, by definition, is not "ASCII" but this "Extended ASCII" thing you refer to in your link. There is no guarantee that your terminal is using this character set, or for that matter your text editor either.

One day I plan to sit down and write up a FAQ about wide characters, character sets, and encodings because this stuff is more complicated than it first appears. As evidenced by questions like "How do I print this extended ASCII character" when there is in fact no such thing as "extended ASCII."

---

Kindly do it soon,I wanna learn it!. :D

Off-topic:
BTW, it was very cool of you to use Rabin-Miller algorithm for that prime number contest.
Before that i have never heard of probabilistic algorithms. :)

Any characters within your source file that are not within the "basic character set" are handled in a implementation defined manner. The basic character set is:

Code:

---

a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
_ { } [ ] # ( ) < > &#37; : ; . ? * + - / ˆ & | ˜ ! = , \ " ’

---

So to understand what's going on, you first need to know about code pages. A code page defines what glyph you should see for a particular 8-bit character code. The "basic character set" typically has the same glyph-to-code mapping in all code pages - making them nice and portable. If you go outside this basic set of characters, you then need to know how your text editor is saving the file - and make sure that the format is compatible with the "implementation defined" behavior your compiler.

Here's a nice site that lists several Unicode characters along with any code pages in which the character appears. Here is "Latin Small Letter A With Diaeresis": http://www.tachyonsoft.com/uc0000.htm#U00E4
As you can see, it has an ASCII value of 0x84 in a handful of code pages, and 0xE4 in a handful of others.

In Windows, your typical text editor will encode an ASCII text file using the system's "ANSI Code Page" (ACP). For my system, that's 1252, where ä == 0xE4 or 228.

So let's say you've been real careful to ensure that your source code contains the character code that you expect - let's say '\xE4'. This still isn't of very much use because now you have to worry about what code page the console is actually using to display characters.
Under Windows, there's the additional hassle of knowing what font the console is using. For example, on my machine, if the console is using "raster fonts", then the glyphs are limited to what's in code page 437 (DOS USA) because my installation is localized to the US (making 437 the default "OEM" charset - or the default console output code page). You can change your console's font to use something like Lucida Console, which has several Unicode characters. In this case, the system will take the current console output code page and try to find a matching Unicode glyph.

So if you set your console to use Lucida Console font, the following code will print ä twice:

Code:

---

    SetConsoleOutputCP(1252);
    puts("\xE4");
   
    SetConsoleOutputCP(437);
    puts("\x84");

---

Next tutorial: What's wchar_t good for?

gg

Quote:

---

Originally Posted by Codeplug

Any characters within your source file that are not within the "basic character set" are handled in a implementation defined manner. The basic character set is:

Code:

---

a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
_ { } [ ] # ( ) < > % : ; . ? * + - / ˆ & | ˜ ! = , \ " ’

---

---

Aren't you forgetting: space, tab, CR, LF, NUL?

Yeah, something like that. C99 says:

Quote:

---

... the space character, and control characters representing horizontal tab, vertical tab, and form feed.

---

gg

Wow.That's really a lot of useful information.
Thank you so much for taking time to write that clear and detailed explanation.
Thanks again for sharing codeplug. :)