hex math

Hi
I was presented with the following in a job interview and was asked to provide the output.
Please help me learn from this.

Code:

int main()
{
    char buff[]={ 0x11,0x11,0x11,0x11,0x22,0x22,0x22,0x22,0x33,0x33,0x33,0x33};
    char* pEnd = buff + sizeof(buff) -1;
    long * plong = buff;
    short* pshort = buff;

    for(; plong<pEnd; plong++)
        printf("0x%X\n", plong);

    for(; pshort<pEnd; pshort++)
        printf("0x%X\n", pshort);

    return 0;
}

I now realize that short is 2 bytes and long is 4 bytes.
how does that change on other platforms?

the output is:
0xBFA29F44
0xBFA29F48
0xBFA29F4C
0xBFA29F44
0xBFA29F46
0xBFA29F48
0xBFA29F4A
0xBFA29F4C
0xBFA29F4E
I don't understand why?

A short is almost always 16 bits (unless we're dealing with a machine where a "word" is not a multiple of 16, e.g. DEC-10 or DEC-20 machines that have 36-bit registers, so a "short" would (probably) be 18 bits).

A long may be 32, 64 or some other number of bits. It does not NECESSARILY correspond to the number of bits in a register, as Windows 64-bit is uses 64-bit mode, where registers and memory locations are 64-bit, but the long type is still 32-bit (because the Windows API uses long for many purposes, which they didn't want to break).

--
Mats

Thanks Mats for the explanation.
can anyone please help me understand how the output came to be what it is?

Originally Posted by kroiz

Thanks Mats for the explanation.
can anyone please help me understand how the output came to be what it is?

What part of matsp's explanation did you not understand?

I understand the size of the long and short but I don't understand how making them point to the char array cause that output.

I think you want to write printf("0x%X\n", *plong) and printf("0x%X\n", *pshort).

Originally Posted by King Mir

I think you want to write printf("0x%X\n", *plong) and printf("0x%X\n", *pshort).

Wonderful, now it all makes sense.
Thanks a lot.

Who knew that taking 0x11 and shifting it left 8 times would produce 0x1100. Damn hex math...
oh well maybe next job interview....

Originally Posted by kroiz

Who knew that taking 0x11 and shifting it left 8 times would produce 0x1100. Damn hex math...
oh well maybe next job interview....

Most people. You may want to think about learning basic stuff like this before you try to go in an get a job programming.

Originally Posted by MeTh0Dz

Most people. You may want to think about learning basic stuff like this before you try to go in an get a job programming.

(-: I've been programming very successfully for 8 years w/o it.

Obviously not at the lower levels...

--
Mats

What level requires hex knowledge? hardware?

Originally Posted by kroiz

What level requires hex knowledge? hardware?

Well, any time you shuffle bits around, hex is a nice representation of binary numbers - so you get used to calculating them in your head after a while. I've also found it useful for translating Miles-per-hour to Km-per-hour and vice versa, since the ratio is 1.6, base-16 conversion works fairly well for a "close enough" estimate.

--
Mats

This problem didn't have much to do with hex knowledge, but about incrementing pointers to different sized things, along a character buffer.

You can do hex math o.O? Damn there's much to learn! And too much to read >.<