«

On Dec 25, 4:52*pm, santosh <santosh....@gmail.com> wrote:
> somenath wrote:
>
> <snip>
>
> > I am unable to understand the conversation
> > Let me explain my understanding .
>
> > int x = 0xFFFFFFF0;
> > signed char y;
> > y = x;
>
> > In these three statements y is guaranteed to contain the last byte of
> > the integer.
>
> No it's not. How can it be when 'x' isn't guaranteed to hold 0xfffffff
> in the first place. Use a smaller value like 0x7fff.
>
> > As my machine is Little endian y wil be equal to F0 i.e
> > 240 in decimal.
> > Now when I print using %x it should print the hexadecimal
> > representation of 240 i.e F0 .Why it is printing fffffff0 ?
>
> Because of format specifier mismatch. You are supplying a char and
> telling it to look for an int. As a result, printf accesses more bytes
> than it should and prints whatever happens to be in the extra bytes.
> Use the 'hhx' format specifier and try again. Also use a cast for the
> assignment to 'y'.


I have changed the code as below

#include <stdio.h>
int main(void)
{
int x = 0x7fff;
signed char y;
y =(signed char) x;
printf("%hhx\n", y);
return 0;


}
Now is it guaranteed that y will hold ff which is the last byte of x ?

Now the output is ffffffff
Why it is not ff only ?

On Tue, 25 Dec 2007 17:22:13 +0530, santosh wrote:
> somenath wrote:
>> int x = 0xFFFFFFF0;
>> signed char y;
>> y = x;
>
> [...] Also use a cast for the assignment to 'y'.

Why? There is an implicit conversion from int to signed char, which
behaves exactly the same as an explicit conversion from int to signed
char.

somenath wrote:

> On Dec 25, 4:52*pm, santosh <santosh....@gmail.com> wrote:
>> somenath wrote:
>>
>> <snip>
>>
>> > I am unable to understand the conversation
>> > Let me explain my understanding .
>>
>> > int x = 0xFFFFFFF0;
>> > signed char y;
>> > y = x;
>>
>> > In these three statements y is guaranteed to contain the last byte
>> > of the integer.
>>
>> No it's not. How can it be when 'x' isn't guaranteed to hold
>> 0xfffffff in the first place. Use a smaller value like 0x7fff.
>>
>> > As my machine is Little endian y wil be equal to F0 i.e
>> > 240 in decimal.
>> > Now when I print using %x it should print the hexadecimal
>> > representation of 240 i.e F0 .Why it is printing fffffff0 ?
>>
>> Because of format specifier mismatch. You are supplying a char and
>> telling it to look for an int. As a result, printf accesses more
>> bytes than it should and prints whatever happens to be in the extra
>> bytes. Use the 'hhx' format specifier and try again. Also use a cast
>> for the assignment to 'y'.
>
>
> I have changed the code as below
>
> #include <stdio.h>
> int main(void)
> {
> int x = 0x7fff;
> signed char y;
> y =(signed char) x;
> printf("%hhx\n", y);
> return 0;
>
>
> }
> Now is it guaranteed that y will hold ff which is the last byte of x ?
>
> Now the output is ffffffff
> Why it is not ff only ?

I get 'ff' here. What compiler are you using and what are the options
that you are passing it?

santosh wrote:
>> I have changed the code as below
>>
>> #include <stdio.h>
>> int main(void)
>> {
>> int x = 0x7fff;
>> signed char y;
>> y =(signed char) x;
>> printf("%hhx\n", y);
>> return 0;
>>
>>
>> }
>> Now is it guaranteed that y will hold ff which is the last byte of x ?
>>
>> Now the output is ffffffff
>> Why it is not ff only ?
>
> I get 'ff' here. What compiler are you using and what are the options
> that you are passing it?
>

I get ff here too

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

santosh wrote:
> somenath wrote:
>>
>> #include <stdio.h>
>> int main(void)
>> {
>> int x = 0x7fff;
>> signed char y;
>> y =(signed char) x;
>> printf("%hhx\n", y);
>> return 0;
>>
>>
>> }
>> Now is it guaranteed that y will hold ff which is the last byte of x ?
>>
>> Now the output is ffffffff
>> Why it is not ff only ?
>
> I get 'ff' here. What compiler are you using and what are the options
> that you are passing it?
>

gcc produces ff
lcc-win produces ff
msvc (2005) produces ffff

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> santosh wrote:
>>> I have changed the code as below
>>>
>>> #include <stdio.h>
>>> int main(void)
>>> {
>>> int x = 0x7fff;
>>> signed char y;
>>> y =(signed char) x;
>>> printf("%hhx\n", y);
>>> return 0;
>>>
>>>
>>> }
>>> Now is it guaranteed that y will hold ff which is the last byte of x ?
>>>
>>> Now the output is ffffffff
>>> Why it is not ff only ?
>>
>> I get 'ff' here. What compiler are you using and what are the options
>> that you are passing it?
>>
>
> I get ff here too
>
I took the liberty of changing the code again..

#include <stdio.h>
int main(void)
{
int x = 0x7fff;
char y;
y = x;
printf("%hx\n", y);
return 0;
}
None of the casting was necessary and "%hhx" is weird. This prints ffff
just as I expect it to. What is the case for ff?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Joe Wright wrote:
> jacob navia wrote:
>> santosh wrote:
>>>> I have changed the code as below
>>>>
>>>> #include <stdio.h>
>>>> int main(void)
>>>> {
>>>> int x = 0x7fff;
>>>> signed char y;
>>>> y =(signed char) x;
>>>> printf("%hhx\n", y);
>>>> return 0;
>>>>
>>>>
>>>> }
>>>> Now is it guaranteed that y will hold ff which is the last byte of x ?
>>>>
>>>> Now the output is ffffffff
>>>> Why it is not ff only ?
>>>
>>> I get 'ff' here. What compiler are you using and what are the options
>>> that you are passing it?
>>>
>>
>> I get ff here too
>>
> I took the liberty of changing the code again..
>
> #include <stdio.h>
> int main(void)
> {
> int x = 0x7fff;
> char y;
> y = x;
> printf("%hx\n", y);
> return 0;
> }
> None of the casting was necessary and "%hhx" is weird. This prints ffff
> just as I expect it to. What is the case for ff?
>

See my other reply. I think Microsoft has a bug here

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Old Wolf wrote:
> On Dec 25, 5:57 pm, somenath <somenath...@gmail.com> wrote:
>> #include <stdio.h>
>> int main(void)
>> {
>> int x = 0xFFFFFFF0;
>> signed char y;
>> y = x;
>> printf("%x\n", y);
>> return 0;}
>>
>> Output of the program is
>>
>> fffffff0
>>
> ...
>> 2) And in the explanation it says %x promote y to an integer but I
>> think it converts its argument to hexadecimal.
>> Is my understanding wrong?
>
> The behaviour is undefined because you have to explicitly
> pass an unsigned int for %x , the compiler doesn't do any
> conversions.

The compiler DOES convert from signed char to int, but the end result is
undefined because the result of interpreting an int with negative value as
an unsigned int is undefined.

--
Thad

jacob navia wrote:
> Joe Wright wrote:
>> jacob navia wrote:
>>> santosh wrote:
>>>>> I have changed the code as below
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void)
>>>>> {
>>>>> int x = 0x7fff;
>>>>> signed char y;
>>>>> y =(signed char) x;
>>>>> printf("%hhx\n", y);
>>>>> return 0;
>>>>>
>>>>>
>>>>> }
>>>>> Now is it guaranteed that y will hold ff which is the last byte of x ?
>>>>>
>>>>> Now the output is ffffffff
>>>>> Why it is not ff only ?
>>>>
>>>> I get 'ff' here. What compiler are you using and what are the options
>>>> that you are passing it?
>>>>
>>>
>>> I get ff here too
>>>
>> I took the liberty of changing the code again..
>>
>> #include <stdio.h>
>> int main(void)
>> {
>> int x = 0x7fff;
>> char y;
>> y = x;
>> printf("%hx\n", y);
>> return 0;
>> }
>> None of the casting was necessary and "%hhx" is weird. This prints
>> ffff just as I expect it to. What is the case for ff?
>>
>
> See my other reply. I think Microsoft has a bug here
>
My compiler is gcc (djgpp) and I get ffff. If msvc gets ffff too I don't
see the 'bug' you suggest. Once x is assigned to y the value of y is -1.
In the printf the value of y is promoted to int (still -1) and displayed
as unsigned short (ffff). In order to print ff the value of y must be
255 and there is no case for that here. Could be lcc-win is broke.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Joe Wright wrote:
> jacob navia wrote:
>> Joe Wright wrote:
>>> jacob navia wrote:
>>>> santosh wrote:
>>>>>> I have changed the code as below
>>>>>>
>>>>>> #include <stdio.h>
>>>>>> int main(void)
>>>>>> {
>>>>>> int x = 0x7fff;
>>>>>> signed char y;
>>>>>> y =(signed char) x;
>>>>>> printf("%hhx\n", y);
>>>>>> return 0;
>>>>>>
>>>>>>
>>>>>> }
>>>>>> Now is it guaranteed that y will hold ff which is the last byte of
>>>>>> x ?
>>>>>>
>>>>>> Now the output is ffffffff
>>>>>> Why it is not ff only ?
>>>>>
>>>>> I get 'ff' here. What compiler are you using and what are the options
>>>>> that you are passing it?
>>>>>
>>>>
>>>> I get ff here too
>>>>
>>> I took the liberty of changing the code again..
>>>
>>> #include <stdio.h>
>>> int main(void)
>>> {
>>> int x = 0x7fff;
>>> char y;
>>> y = x;
>>> printf("%hx\n", y);
>>> return 0;
>>> }
>>> None of the casting was necessary and "%hhx" is weird. This prints
>>> ffff just as I expect it to. What is the case for ff?
>>>
>>
>> See my other reply. I think Microsoft has a bug here
>>
> My compiler is gcc (djgpp) and I get ffff. If msvc gets ffff too I don't
> see the 'bug' you suggest. Once x is assigned to y the value of y is -1.
> In the printf the value of y is promoted to int (still -1) and displayed
> as unsigned short (ffff). In order to print ff the value of y must be
> 255 and there is no case for that here. Could be lcc-win is broke.
>


I was speaking about the second version, and did not see that you
have changed it AGAIN. After that change I get ffff again.

The bug I was referring to was for this code
#include <stdio.h
int main(void)
{
int x = 0x7fff;
signed char y;
y =(signed char) x;
printf("%hhx\n", y);
return 0;


}




--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32