printf and cout

[laikon]

Hello, everyone:

this is about overflow in C and C++.

int c = 400;
printf("%c", c);

it print ? on screen, and ascii of '?' is 63.

but
cout << int(char(400));

it print -112 on screen.

so, my question is why comes 63 and -112, what relations between them,
why printf and cout behavior so differently.

all the tests are in VC2005.

thanks a lot.

 

[Richard Heathfield]

laikon said:

Hello, everyone:

this is about overflow in C and C++.

The behaviour of a C program on overflow is undefined.

int c = 400;
printf("%c", c);

it print ? on screen,

Not necessarily. C doesn't guarantee you a screen, and it says very little
about the character set supplied by your implementation.

and ascii of '?' is 63.

This is irrelevant, I think. If by some chance you'd seen the character
with code point 144 (which is, of course, *not* an ASCII character), I'd
have been able to explain it in concrete terms. I am a little puzzled by
the 63, actually. Try dumping the character to a file and examining a hex
dump thereof.

but
cout << int(char(400));

it print -112 on screen.

You might want to ask that in comp.lang.c++

 

[Bernhard Schauer]

int c = 400;

printf("%c", c);

it print ? on screen, and ascii of '?' is 63.

but
cout << int(char(400));

it print -112 on screen.

so, my question is why comes 63 and -112, what relations between them,
why printf and cout behavior so differently.

Hi!

both values are the same, except that the '?' is not meant as the
character '?' but as an unprintable character. It also "looks" different
than a normal '?'.

regards

 

[laikon]

laikon said:



The behaviour of a C program on overflow is undefined.



Not necessarily. C doesn't guarantee you a screen, and it says very little
about the character set supplied by your implementation.


This is irrelevant, I think. If by some chance you'd seen the character
with code point 144 (which is, of course, *not* an ASCII character), I'd
have been able to explain it in concrete terms. I am a little puzzled by
the 63, actually. Try dumping the character to a file and examining a hex
dump thereof.



You might want to ask that in comp.lang.c++

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

thanks very much.

I just know:

the printed '?' does not mean to be the result of the overflow, but a
symbol of unknown ascii character. when a number overflows by char,
and the left binary is negate, the printf will print '?'.

 

[Richard Heathfield]

laikon said:

I just know:

the printed '?' does not mean to be the result of the overflow, but a
symbol of unknown ascii character.

There aren't any unknown ASCII characters. If the printed '?' /is/ an ASCII
character, then it has code point 63. If it hasn't, then it isn't an ASCII
character.

when a number overflows by char,
and the left binary is negate, the printf will print '?'.

No, printf offers no such guarantee.

 

[santosh]

Hello, everyone:

this is about overflow in C and C++.

int c = 400;
printf("%c", c);

it print ? on screen, and ascii of '?' is 63.

No, actually it prints a ? character, which is not defined either in the
basic C character set or in ASCII.

but
cout << int(char(400));

it print -112 on screen.

Try this printf statement:

printf("c = %d\nc (cast to unsigned char) = %d\t%c\n",
c, (unsigned char)c, c);

so, my question is why comes 63 and -112, what relations between them,
why printf and cout behavior so differently.

Actually they don't behave differently at all. In each case the int
value 400 is being interpreted as an unsigned char. The result of this
conversion gives the value 144, which is not a valid ASCII code.
However all modern systems have one or more "extended" ASCII code pages
active and on your system the value 144 happens to map to the ?
character.

<snip>

 

[santosh]

No, actually it prints a ? character, which is not defined either in
the basic C character set or in ASCII.


Try this printf statement:

printf("c = %d\nc (cast to unsigned char) = %d\t%c\n",
c, (unsigned char)c, c);


Actually they don't behave differently at all. In each case the int
value 400 is being interpreted as an unsigned char. The result of this
conversion gives the value 144, which is not a valid ASCII code.
However all modern systems have one or more "extended" ASCII code
pages active and on your system the value 144 happens to map to the ?
character.

<snip>

Actually it is used as a placeholder by your system to indicate that an
appropriate conversion could not be done.

 

[Bernhard Schauer]

There aren't any unknown ASCII characters. If the printed '?' /is/ an
ASCII character, then it has code point 63. If it hasn't, then it isn't an
ASCII character.

Thats ok. But if there is a number as character printed (depending on the
locale, thus not guaranteed to be ASCII) that is "unprintable" (control
codes, ...) a special character may be inserted by the terminal - it looks
like a question mark (it may also be one).

On my computer a white question mark on a black background is printed.

regards,

 

[Richard Heathfield]

santosh said:

laikon wrote:


No, actually it prints a ? character, which is not defined either in the
basic C character set or in ASCII.

The '?' question mark *is* in fact part of the basic C character set. It is
used in trigraphs, and as part of the ? : conditional operator.

<snip>

 

[Bernhard Schauer]

santosh wrote:

Actually they don't behave differently at all. In each case the int
value 400 is being interpreted as an unsigned char.

<snip>

Code from laikon:

int c = 400;
printf("%c", c);
cout << int(char(400));

Where exactly do you see unsigned characters? (char != unsigned char)

regards,

 

[santosh]

santosh said:

The '?' question mark *is* in fact part of the basic C character set.
It is used in trigraphs, and as part of the ? : conditional operator.

<snip>

Well it appears as a question mark on Usenet but it's actually a symbol
(a white question mark inside a black diamond) that corresponds to the
octal sequence '\357' '\277' '\275', used to represent a character code
value that is unknown in the encoding used.

This is for my system. It would probably be different under other
systems.

 

[santosh]

santosh wrote:


<snip>

Code from laikon:

Where exactly do you see unsigned characters? (char != unsigned char)

The %c format expects (and thus treats the corresponding argument as) an
unsigned char.

 

[Richard Heathfield]

Bernhard Schauer said:

santosh wrote:


<snip>

Code from laikon:

Where exactly do you see unsigned characters? (char != unsigned char)

When printf is handed a %c, it converts the corresponding int argument to
an unsigned char. See 4.9.6.1 of C89 or 7.19.6.1(8) of C99.

 

[Bernhard Schauer]

When printf is handed a %c, it converts the corresponding int argument to

an unsigned char. See 4.9.6.1 of C89 or 7.19.6.1(8) of C99.

Good to know ;-)

 

[Bernhard Schauer]

The %c format expects (and thus treats the corresponding argument as) an
unsigned char.

Ok. But I hope char(400) does not convert to an unsigned char?

 

[Chris Dollin]

Bernhard Schauer said:


Actually, char(400) converts to a syntax error.

But the code it appears in is, atopically, C++, and so how it behaves
in C doesn't much matter ...

The C equivalentish code, `(char) 400`, doesn't convert to unsigned
char, but to char -- which may be an unsigned type, or not, at the
implementor's whim, perhaps with an eye on performance implications
(and mobs with torches and pitchforks).

 

[Richard Heathfield]

Bernhard Schauer said:

Ok. But I hope char(400) does not convert to an unsigned char?

Actually, char(400) converts to a syntax error.

 

[Bernhard Schauer]

Actually, char(400) converts to a syntax error.

Sorry. Mixed up C/C++ (again). Meant (char)400 as Chris pointed out.

 

[Kenneth Brody]

Richard Heathfield wrote:

[... Snipped context: printf's "%c" output of (char)144 equivalent ...]

Thats ok. But if there is a number as character printed (depending on the
locale, thus not guaranteed to be ASCII) that is "unprintable" (control
codes, ...) a special character may be inserted by the terminal - it looks
like a question mark (it may also be one).

On my computer a white question mark on a black background is printed.

I get a capital E-acute when printing character 144.

<!ENTITY Eacute CDATA "É" -- latin capital letter E with acute,
U+00C9 ISOlat1 -->

The point being: C doesn't guarantee ASCII, and ASCII doesn't guarantee
anything above 0x7f.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Mark McIntyre]

laikon said:


The behaviour of a C program on overflow is undefined.


Not necessarily. C doesn't guarantee you a screen, and it says very little
about the character set supplied by your implementation.


This is irrelevant, I think. If by some chance you'd seen the character
with code point 144 (which is, of course, *not* an ASCII character), I'd
have been able to explain it in concrete terms. I am a little puzzled by
the 63, actually.

Its not printing 63, its just printing "?" to mean "I don't know how to
represent a value outside the characterset this screen uses".