Redeclarations

[legion050]

not exactly sure why this doesnt work.
im taking an example from a free stanford online video but ^when compiled' it doesnt give the answer i was looking for which is the letter 'a' or number '65'

#include <stdio.h>

int main()
{
unsigned short one=1;
unsigned char two;

printf("hello world %d\n",one);
one=one << 15;
printf("hello world %d\n",one);
two = *(unsigned char*)&one;//this line gives an answer that i didnt expect
++two;
printf("hello world %d\n",two);

return 0;
}

if you could help me figure out why "char two" would reset to zero on the commented line.

[legion050]

is there any more information needed? or am I missing something super simple?

[cas]

You shouldn't expect a particular answer, because the result of this will be system dependent.

You're looking at the first byte of “one”, which at this point has the value 1<<15, or 0x8000. Presuming a 16-bit short, you have two bytes, one of which is 0x80, the other is 0x00. However, in memory, this will be stored one of two different ways (technically there could be more, but there aren't in practice):

either the byte 0x80 comes first, then 0x00, or the byte 0x00 comes first, then 0x80. The first is called big-endian, the second, little-endian. Thus “two” will contain either 0x80 or 0x00. If you increment that, you will get either 0x81 or 0x01.

I'm not sure why you were expecting 'a'. Pointing an unsigned char* at an object allows you to examine it byte-by-byte and has nothing (inherently) to do with printable characters.

[CommonTater]

not exactly sure why this doesnt work.
im taking an example from a free stanford online video but ^when compiled' it doesnt give the answer i was looking for which is the letter 'a' or number '65'

#include <stdio.h>

int main()
{
unsigned short one=1;
unsigned char two;

printf("hello world %d\n",one);
one=one << 15;
printf("hello world %d\n",one);
two = *(unsigned char*)&one;//this line gives an answer that i didnt expect
++two;
printf("hello world %d\n",two);

return 0;
}

if you could help me figure out why "char two" would reset to zero on the commented line.

Ok follow the values of your variables...

unsigned short one = 1 = 0000000000000001
one << 15 = 1000000000000000
char *two = &one = 10000000
++two = 1 | 00000000 (0 with 1 in the CPU carry flag)
two = 0;

It is giving you the correct answer.

[legion050]

appreciate the quick answers!

You shouldn't expect a particular answer, because the result of this will be system dependent.

yeah, I shouldnt, I just thought I had the bits going where I wanted.. XD

what appears to be my problem I "think" is endianness
what I was trying to do was..

[00000000][00000001]
[01000000][00000000] one=one << 14;
*[01000000]**[00000000] two = *(unsigned char*)&one;
*[01000001]**[00000000] ++two;

what I did that compiled with the answer i wanted was much simpler..

[00000000][00000001]
[00000000][01000000] one=one << 6;
[00000000]**[01000000] two = *(unsigned char*)&one;
[00000000]**[01000001] ++two;

*underlined is what i wanted in the variable
**italic is put into the variable


love this forum and the help you guys give.
ty very much!
EDIT: .................................................. ................
actually i should change my wording.

first one is what i tried to do to get to what i want.

what i was "wanting" to do is/was
(this is a problem i invented myself to test how this stuff works so you may wonder what i am leading to lol)

in bit form turn


2^0 bit-shift it to
2^14 and then add a bit to the 2^9
the look at the short as a character to make it appear as it is
2^6 + 2^0 = 65 or A

[CommonTater]

what appears to be my problem I "think" is endianness

I may stand to be corrected on this but I really don't think "endianness" should matter in this case... Especially between code bits in the same program. The compiler should compensate for that so that the same source code gives the same results on either BE or LE machines...

[anduril462]

I may stand to be corrected on this but I really don't think "endianness" should matter in this case... Especially between code bits in the same program. The compiler should compensate for that so that the same source code gives the same results on either BE or LE machines...

Unfortunately, that's not the case. If we were dealing with just casting the integer values, then it might be so, but definitely not when dealing with pointers. one is a short, meaning it takes up two bytes, let's say at address 0x1000 and 0x1001. Thus, &one is 0x1000, whether big or little endian. The endianness doesn't affect the base address of a variable, i.e. the address of a multi-byte integer doesn't always correspond with the most significant byte. It's always the lowest address of it's bytes. Casting the address of one to a unsigned char * gives a pointer to a single byte at address 0x1000. Whether that's the MSB or LSB depends on the endianness of the system.

If you were to do

two = (unsigned char) one;

the results would be, as you expect, the LSB of one.