Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > char change to int, very wired

Reply
Thread Tools

char change to int, very wired

 
 
pembed2012
Guest
Posts: n/a
 
      06-08-2012
Dear all,

I need you help.

here the program:

char a = 0x91;

printf("%x",a);

result: ff ff ff 91

now, i was confused with the result. I think it is 91. but it seems
convert to something.

why?

btw, compiler:gcc machine x86 intel
thanks
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      06-08-2012
pembed2012 <(E-Mail Removed)> writes:
>printf("%x",a);


Try "%hhx\n".

 
Reply With Quote
 
 
 
 
Jean-Christophe
Guest
Posts: n/a
 
      06-08-2012
On 8 juin, 21:46, pembed2012

> char a = 0x91;
> printf("%x",a);
> result: ff ff ff 91
> why?


'char' means 'signed char' so the
value 0x91 is negative = -111 decimal

printf( "%x", (unsigned char)a );
result: 91
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      06-08-2012
On 06/08/2012 03:46 PM, pembed2012 wrote:
> Dear all,
>
> I need you help.
>
> here the program:
>
> char a = 0x91;
>
> printf("%x",a);
>
> result: ff ff ff 91
>
> now, i was confused with the result. I think it is 91. but it seems
> convert to something.


char can be either signed or unsigned. If were unsigned, a would have a
value of 91. If it were signed, 0x91 would likely to be greater than
INT_MAX, in which case it the conversion to char will either produce an
implementation-defined result, or raise an implementation-defined
signal. Unless you happen to have set up a signal handler for the
appropriate signal, I think we can rule out that possibility in this case.

As a result, the value of 'a' could be any char value, but the most
likely case is that it's 0x91, interpreted as an 8-bit 2's complement
signed value, which would be a negative number.

Whether or not 'a' is signed, it's probably the case that CHAR_MAX <
INT_MAX on your machine, in which case it's value gets promoted to an
'int' in the call to printf(). That's where all of the extra 'ff's
probably come from. The "%x" specifier expects a unsigned int argument;
as a result, the behavior of your call is undefined. However, on many
systems it's likely to print out the same value you would get from
printing (unsigned)(int)a with the same format specifier. That would
appear to be ffffff91 on
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      06-08-2012
On 06/08/2012 04:16 PM, Jean-Christophe wrote:
> On 8 juin, 21:46, pembed2012
>
>> char a = 0x91;
>> printf("%x",a);
>> result: ff ff ff 91
>> why?

>
> 'char' means 'signed char' so the


No, that's the way it works for short, int, long, and long long: signed
short and short are the same exact type. However, for the character
types, the rules are different. "char" is its own unique type, distinct
from both unsigned char and signed char. It's required to have exactly
the same representation as either "signed char" or "unsigned char"
(6.2.5p15). If CHAR_MIN is 0, then char is unsigned, and if CHAR_MIN is
negative, char is signed.


 
Reply With Quote
 
Joe Pfeiffer
Guest
Posts: n/a
 
      06-08-2012
pembed2012 <(E-Mail Removed)> writes:

> Dear all,
>
> I need you help.
>
> here the program:
>
> char a = 0x91;
>
> printf("%x",a);
>
> result: ff ff ff 91
>
> now, i was confused with the result. I think it is 91. but it seems
> convert to something.


Others have given good answers in terms of the defined language
semantics. The nuts-and-bolts of what you're seeing is that in the
conversion from char to int, the char is being interpreted as a signed
char, so the most significant bit is a 1. That's being sign-extended
(hence the ff ff ff).

Are you sure it's ff ff ff 91, and not ffffff91?
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      06-09-2012
On 06/08/2012 06:47 PM, Keith Thompson wrote:
> James Kuyper <(E-Mail Removed)> writes:

....
>> char can be either signed or unsigned. If were unsigned, a would have a
>> value of 91.

>
> You mean 0x91.
>
>> If it were signed, 0x91 would likely to be greater than
>> INT_MAX,

>
> You mean CHAR_MAX.


You're right, of course.
Sigh.
--
James Kuyper
 
Reply With Quote
 
pembed2012
Guest
Posts: n/a
 
      06-09-2012
On Fri, 08 Jun 2012 16:16:46 -0400, James Kuyper wrote:

> On 06/08/2012 03:46 PM, pembed2012 wrote:
>> Dear all,
>>
>> I need you help.
>>
>> here the program:
>>
>> char a = 0x91;
>>
>> printf("%x",a);
>>
>> result: ff ff ff 91
>>
>> now, i was confused with the result. I think it is 91. but it seems
>> convert to something.

>
> char can be either signed or unsigned. If were unsigned, a would have a
> value of 91. If it were signed, 0x91 would likely to be greater than
> INT_MAX, in which case it the conversion to char will either produce an
> implementation-defined result, or raise an implementation-defined
> signal. Unless you happen to have set up a signal handler for the
> appropriate signal, I think we can rule out that possibility in this
> case.
>
> As a result, the value of 'a' could be any char value, but the most
> likely case is that it's 0x91, interpreted as an 8-bit 2's complement
> signed value, which would be a negative number.
>
> Whether or not 'a' is signed, it's probably the case that CHAR_MAX <
> INT_MAX on your machine, in which case it's value gets promoted to an
> 'int' in the call to printf(). That's where all of the extra 'ff's
> probably come from. The "%x" specifier expects a unsigned int argument;
> as a result, the behavior of your call is undefined. However, on many
> systems it's likely to print out the same value you would get from
> printing (unsigned)(int)a with the same format specifier. That would
> appear to be ffffff91 on


i don't understand any of this, what signal handler!!

if it is overflow why the value should be bit pattern?
is it a rule or something else?
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      06-09-2012


"pembed2012" <(E-Mail Removed)> wrote in message
news:jqtkr1$6nc$(E-Mail Removed)...
> Dear all,
>
> I need you help.
>
> here the program:
>
> char a = 0x91;
>
> printf("%x",a);
>
> result: ff ff ff 91
>
> now, i was confused with the result. I think it is 91. but it seems
> convert to something.


Your char type probably only stores values from -128 to 127 (or -0x80 to
+0x7F). Your 0x91 value is 145, outside the range. So funny things happen
which are difficult to understand.

Just use 'unsigned char' instead, which likely has a range of 0 to 255, or
0x00 to 0xFF.

--
Bartc

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      06-09-2012
pembed2012 <(E-Mail Removed)> writes:

> On Fri, 08 Jun 2012 16:16:46 -0400, James Kuyper wrote:
>
>> On 06/08/2012 03:46 PM, pembed2012 wrote:
>>> Dear all,
>>>
>>> I need you help.
>>>
>>> here the program:
>>>
>>> char a = 0x91;
>>>
>>> printf("%x",a);
>>>
>>> result: ff ff ff 91
>>>
>>> now, i was confused with the result. I think it is 91. but it seems
>>> convert to something.

>>
>> char can be either signed or unsigned. If were unsigned, a would have a
>> value of 91. If it were signed, 0x91 would likely to be greater than
>> INT_MAX, in which case it the conversion to char will either produce an
>> implementation-defined result, or raise an implementation-defined
>> signal. Unless you happen to have set up a signal handler for the
>> appropriate signal, I think we can rule out that possibility in this
>> case.
>>
>> As a result, the value of 'a' could be any char value, but the most
>> likely case is that it's 0x91, interpreted as an 8-bit 2's complement
>> signed value, which would be a negative number.
>>
>> Whether or not 'a' is signed, it's probably the case that CHAR_MAX <
>> INT_MAX on your machine, in which case it's value gets promoted to an
>> 'int' in the call to printf(). That's where all of the extra 'ff's
>> probably come from. The "%x" specifier expects a unsigned int argument;
>> as a result, the behavior of your call is undefined. However, on many
>> systems it's likely to print out the same value you would get from
>> printing (unsigned)(int)a with the same format specifier. That would
>> appear to be ffffff91 on

>
> i don't understand any of this, what signal handler!!


The C standard says that the conversion of a value that is out of range
to a signed integer type is "implementation defined" or it may "raise an
implementation defined signal". On your system, plain char is signed so
it is a signed integer type, and the value, 0x91, is out of range for a
single-byte char so the above rule applies.

"Implementation defined" has a precise meaning in the C standard. It
means that the documentation for the implementation (often called rather
loosely "the compiler") must say what happens. Few implementations
choose to raise a signal when converting an out-of-range signed integer
value. Yours is one that does not. Most C implementation define the
conversion as simply copying as many of the low-order bits as are needed
from the source to the target.

> if it is overflow why the value should be bit pattern?
> is it a rule or something else?


It's not, technically, an overflow. Overflows can occur as the result
of arithmetic, but an out-of-range conversion is not really an
overflow -- it's just a conversion.

Your program does several rather odd things. All of them mean that the
results say more about what the compiler and the machine are doing
rather than what the C language says about your program. Here is the
highly system-specific description of what is happening:

First, the int value 145 is converted a char type value. On your
system, char objects can hold valued from -128 to 127 so 145 is
out-of-range. This conversion done by simply taking the bottom 8 bits
of

00000000000000000000000010010001

(that 145 as a 32-bit int) and stuffing them into the 8 bits of the char
called 'a'.

The program then needs the value of 'a', and it needs it converted to a
int, because the arguments to variadic functions like printf have what
are called "the integer promotions" applied to them. The char 'a'
contains the bits:

10010001

and your system uses 2's complement representation for signed values.
That means that 10010001 represents the value -111 (to see exactly why,
look up "signed number representation" on, say, Wikipedia). The
conversion of -111 to an int is well-defined (-111 is always in range
for the type int) you just get -111! Of course, with 32-bit ints it
looks like this:

11111111111111111111111110010001

(again, you may need to consult the Web to see exactly why).

Now your program does something even odder. The printf format specifier
%x expects an unsigned int rather than a plain int. This is,
technically, undefined by the C language standard. If you give a value
of the wrong type to printf, anything could happen, but in fact, it is
likely that printf will just plough on and pretend that the

11111111111111111111111110010001

it sees is a unsigned int, and it will go ahead and print it in hex as
requested:

ffffff91

If anyone was in any doubt, this might help explain why C is not a
particularly good vehicle for teaching programming. Simple, short
programs can involve one in long irrelevant explanations, or require the
rather dismissive "you'll understand later after computer architecture
101".

--
Ben.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Wireless can't see Wired, Wired Can't Access Wireless UFGrayMatter Wireless Networking 0 08-14-2006 01:26 AM
(const char *cp) and (char *p) are consistent type, (const char **cpp) and (char **pp) are not consistent lovecreatesbeauty C Programming 1 05-09-2006 08:01 AM
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM
wireless can't access wired. But Wired can access wireless =?Utf-8?B?ZGZhdG92aWM=?= Wireless Networking 5 02-05-2005 08:07 AM
Wired Tools of 2004 from Wired magazine : the Cameras !!! Mike Henley Digital Photography 0 12-06-2004 02:32 AM



Advertisments