[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

Question

Mateusz_madi

6/8/2011 5:32:00 PM

char c= -1;
int x;
x=c;
printf("%d", x);

Result:
-1

Why it is -1? How -1 is represented in char in binary format?

Regards,

Mateusz
15 Answers

Ben Pfaff

6/8/2011 5:36:00 PM

0

Mateusz_madi <madi.czadi@gmail.com> writes:

> char c= -1;
> int x;
> x=c;
> printf("%d", x);
>
> Result:
> -1
>
> Why it is -1? How -1 is represented in char in binary format?

Presumably 'char' is a signed type. It shouldn't be surprising
that a signed integer type should be able to store -1.

The most common way to store -1 as a binary integer is with all
1-bits.
--
Ben Pfaff
http://be...

Keith Thompson

6/8/2011 5:48:00 PM

0

Mateusz_madi <madi.czadi@gmail.com> writes:
> char c= -1;
> int x;
> x=c;
> printf("%d", x);
>
> Result:
> -1
>
> Why it is -1? How -1 is represented in char in binary format?

Caution: The following provides, to quote John Hodgman's book title,
More Information Than You Require.

It printed -1 because you assigned -1 to c, then assigned the value
of c to x, then printed the value of x. I'm surprised that you
find this surprising.

Another interesting question is why it *wouldn't* be -1.

The type "char" (I'll call it "plain char") can be either signed
or unsigned. Either it has the same representation as signed char,
or it has the same representation as unsigned char -- though they're
still three distinct types.

Apparently plain char is signed in your implementation (which is
very common but not universal).

If plain char were an unsigned type, then the initialization
would convert the value -1 from int to char. The rules of
signed-to-unsigned conversion are such that the result is CHAR_MAX-1,
and if plain char is a signed type, then CHAR_MAX-1 is likely to
be 255.

The assignment ``x=c'' then converts the value 255 from char to int.
Since int can (probably) represent the entire range of char, the
conversion yields the same value in the new type, so x gets the
value 255, which is then printed. You can see what would happen
by modifying your program so c is declared as unsigned char rather
than char.

You'll note that several of my statements were qualified with
"likely" or "probably". The number of bits in a char (i.e., in
a byte) is the value of CHAR_BIT, which is defined in <limits.h>
The standard requires CHAR_BIT to be at least 8, but it can legally
be larger.

And if CHAR_BIT is at least 16, then it's possible that int is only
as wide as char. In that case, if plain char is an unsigned type,
then (signed) int can't represent all its values, which affects
the rules for converting from char to int.

You're not likely to run into any systems like this (I never have),
though I understand that DSPs (Digital Signal Processors) commonly
have CHAR_BIT set to 16 or 32.

As for how -1 is represented in char in binary format, there's
probably no good reason for you to care. C's conversion rules
are defined in terms of values, not representations. But on any
system you're likely to encounter, storing -1 in a char (which will
store -1 if char is signed, or CHAR_MAX, probably 255, if char is
unsigned) will *probably* set all the bits to 1. (There are other
possible represntations for signed integers, namely 2's-complement
and 1s'-complement, but few if any modern systems use them.)

And if you got this far without falling asleep, I'm impressed. 8-)}

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Mateusz_madi

6/8/2011 5:49:00 PM

0

On 8 Cze, 19:36, Ben Pfaff <b...@cs.stanford.edu> wrote:
> Mateusz_madi <madi.cz...@gmail.com> writes:
> > char c= -1;
> > int x;
> > x=c;
> > printf("%d", x);
>
> > Result:
> > -1
>
> > Why it is -1? How -1 is represented in char in binary format?
>
> Presumably 'char' is a signed type.  It shouldn't be surprising
> that a signed integer type should be able to store -1.
>
> The most common way to store -1 as a binary integer is with all
> 1-bits.
> --
> Ben Pfaffhttp://be...

Yes, char is signed type but mayby it was wrong asked question I ment:

if char is 8 bit long so -1 is : 1111 1111
and i assign it to int which let's say is 32 bit long, shoudn't int
look like: 0000 0000 0000 1111 ?

Regards,
Mateusz

Ben Pfaff

6/8/2011 5:54:00 PM

0

Mateusz_madi <madi.czadi@gmail.com> writes:

> if char is 8 bit long so -1 is : 1111 1111
> and i assign it to int which let's say is 32 bit long, shoudn't int
> look like: 0000 0000 0000 1111 ?

No. Type conversions in C preserve value, not bit pattern. If
you assign -1, of any integer type, to an object with any other
signed integer type, the destination will have value -1.

I don't understand how you'd come up with the bit pattern that
you suggested anyway. You wrote a total of 16 bits (not 32), and
you only made 4 of them 1-bits (not 8).
--
Ben Pfaff
http://be...

Joe Pfeiffer

6/8/2011 6:50:00 PM

0

Ben Pfaff <blp@cs.stanford.edu> writes:

> Mateusz_madi <madi.czadi@gmail.com> writes:
>
>> if char is 8 bit long so -1 is : 1111 1111
>> and i assign it to int which let's say is 32 bit long, shoudn't int
>> look like: 0000 0000 0000 1111 ?
>
> No. Type conversions in C preserve value, not bit pattern. If
> you assign -1, of any integer type, to an object with any other
> signed integer type, the destination will have value -1.

To amplify (so I'm not disagreeing with Ben here), in general if a
signed value is copied into a larger word, the value of the integer is
preserved if the sign bit is extended across all the new high-order
bits. So, since your sign bit was a 1, all the new bits are 1's as
well. This is called "sign-extending".

> I don't understand how you'd come up with the bit pattern that
> you suggested anyway. You wrote a total of 16 bits (not 32), and
> you only made 4 of them 1-bits (not 8).

I'll guess he meant

0000 0000 0000 0000 0000 0000 1111 1111

Sign-extended, he would actually get

1111 1111 1111 1111 1111 1111 1111 1111

Something else that ought to be noted is that char can be either signed
or unsigned (it's implementation-dependent). If he wants it to be
signed, he should use a signed char.

Keith Thompson

6/8/2011 6:56:00 PM

0

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Ben Pfaff <blp@cs.stanford.edu> writes:
>> Mateusz_madi <madi.czadi@gmail.com> writes:
>>> if char is 8 bit long so -1 is : 1111 1111
>>> and i assign it to int which let's say is 32 bit long, shoudn't int
>>> look like: 0000 0000 0000 1111 ?
>>
>> No. Type conversions in C preserve value, not bit pattern. If
>> you assign -1, of any integer type, to an object with any other
>> signed integer type, the destination will have value -1.
>
> To amplify (so I'm not disagreeing with Ben here), in general if a
> signed value is copied into a larger word, the value of the integer is
> preserved if the sign bit is extended across all the new high-order
> bits. So, since your sign bit was a 1, all the new bits are 1's as
> well. This is called "sign-extending".
>
>> I don't understand how you'd come up with the bit pattern that
>> you suggested anyway. You wrote a total of 16 bits (not 32), and
>> you only made 4 of them 1-bits (not 8).
>
> I'll guess he meant
>
> 0000 0000 0000 0000 0000 0000 1111 1111
>
> Sign-extended, he would actually get
>
> 1111 1111 1111 1111 1111 1111 1111 1111
>
> Something else that ought to be noted is that char can be either signed
> or unsigned (it's implementation-dependent). If he wants it to be
> signed, he should use a signed char.

Sign-extension preserves the value if negative numbers are
represented using 2's-complement. If the implementation uses either
1s'-complement or sign-and-magnitude, then it needs to use some other
method to preserve the value (I'm too lazy to work out the details).

The point is that the standard requires the value to be preserved,
without regard to how either the source or the target is represented,
or how much extra work the implementation has to go through to get
the required result.

A 2's-complement representation makes some operations easier,
which is why it's used so often.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Ben Pfaff

6/8/2011 7:22:00 PM

0

Keith Thompson <kst-u@mib.org> writes:

> Sign-extension preserves the value if negative numbers are
> represented using 2's-complement. If the implementation uses either
> 1s'-complement or sign-and-magnitude, then it needs to use some other
> method to preserve the value (I'm too lazy to work out the details).

I think that ones' complement sign extension is the same as two's
complement sign extension.
--
Ben Pfaff
http://be...

Morris Keesan

6/8/2011 8:53:00 PM

0

On Wed, 08 Jun 2011 13:49:07 -0400, Mateusz_madi <madi.czadi@gmail.com>
wrote:

....
> Yes, char is signed type but mayby it was wrong asked question I ment:
>
> if char is 8 bit long so -1 is : 1111 1111
> and i assign it to int which let's say is 32 bit long, shoudn't int
> look like: 0000 0000 0000 1111 ?

int i = -1;
long int l = i;

assert(sizeof(long) > sizeof(int));
printf("%ld\n", l);

Would it surprise you if this printed -1?
--
Morris Keesan -- mkeesan@post.harvard.edu

Ben Pfaff

6/8/2011 8:55:00 PM

0

"Morris Keesan" <mkeesan@post.harvard.edu> writes:

> int i = -1;
> long int l = i;
>
> assert(sizeof(long) > sizeof(int));
> printf("%ld\n", l);

What is the value of the assertion? Every signed type is capable
of holding -1.
--
Ben Pfaff
http://be...

Kleuskes & Moos

6/8/2011 11:00:00 PM

0

On Jun 8, 9:21 pm, Ben Pfaff <b...@cs.stanford.edu> wrote:
> Keith Thompson <ks...@mib.org> writes:
> > Sign-extension preserves the value if negative numbers are
> > represented using 2's-complement.  If the implementation uses either
> > 1s'-complement or sign-and-magnitude, then it needs to use some other
> > method to preserve the value (I'm too lazy to work out the details).
>
> I think that ones' complement sign extension is the same as two's
> complement sign extension.

I think you would end up with -0, if you operated under that
assumption.