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?

Quote:

---

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).

Quote:

---

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....

Quote:

---

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.

Quote:

---

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?

Quote:

---

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 >.<

Quote:

---

Originally Posted by DaveH

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

---

that is the easy part, at least for me.
I just did not did not realise that putting 0x11 in the first byte of a short and 0x11 in the second byte produce 0x1111 and that *is* hex math. it does not work this way for base 10.

and to tell the truth I doubt that base on this question you can judge a candidate match for a c++ job.

Quote:

---

Originally Posted by kroiz

that is the easy part, at least for me.
I just did not did not realise that putting 0x11 in the first byte of a short and 0x11 in the second byte produce 0x1111 and that *is* hex math. it does not work this way for base 10.

and to tell the truth I doubt that base on this question you can judge a candidate match for a c++ job.

---

That's not so much hex math as it is "eight bits is a byte".

Quote:

---

Originally Posted by tabstop

That's not so much hex math as it is "eight bits is a byte".

---

No, it was a long not a byte and the number for the output was hex and would look differently with decimals, and don't forget this is a test without a computer or a calculator - just a pencil and a paper.
Change the the formated string in the printf from "0x%X\n" to "%d\n" and tell me - can you predict the result w/o a calculator or a computer?

Quote:

---

Originally Posted by kroiz

No, it was a long not a byte and the number for the output was hex and would look differently with decimals, and don't forget this is a test without a computer or a calculator - just a pencil and a paper.
Change the the formated string in the printf from "0x%X\n" to "%d\n" and tell me - can you predict the result w/o a calculator or a computer?

---

What I mean is that realizing that the answer is 0x1111 is not "hex math" but "there are eight bits in a byte" -- you can solve the problem if and only if you know that there are eight bits in a byte (and also, I suppose, that 0x11 is eight bits long).

Without a calculator? It wouldn't take long to turn 0x11111111 into decimal (it wouldn't be fun, but you could do it); start with one and repeat (times 16 plus 1) seven times for Horner's method. If you mean I had decimals, then same idea but (times 256 plus new number) each time through.

Quote:

---

Originally Posted by tabstop

What I mean is that realizing that the answer is 0x1111 is not "hex math"...

---

Yes it is, because if you take a long and you put in every byte, a hex number, only with hex you would get a number that looks like all the hex numbers "concatenated". that is just a property of hex.

here is an exercise for you: take the decimal number 2 and put it in every one of the 8 bytes of a long. what a decimal number would this long carry?

now do the same exercise but instead of decimal do it with hexadecimal.
Do you see how simple it suddenly became?
That is because of the property of hexadecimal numbers that you can just put one next to the other and get a "concatenated" number.

I only needed to know this to successfully write the solution and if you would ask that exercise like 10 years ago when I was in collage, I would solve it with ease. but due to lack of usefulness (for me) the hex math slipped my mind.
I am pretty sure I wont forget that now. :D

Quote:

---

Originally Posted by kroiz

that is the easy part, at least for me.
I just did not did not realise that putting 0x11 in the first byte of a short and 0x11 in the second byte produce 0x1111 and that *is* hex math. it does not work this way for base 10.

and to tell the truth I doubt that base on this question you can judge a candidate match for a c++ job.

---

I'm still at a loss as to what shifting 0x11 has to do with this problem. The only thing you are printing is the value of the pointers, the address they point to. The output will be different on different computers because the address of buff[] will be different on them. Basically, the interviewers wanted you to demonstrate that you understood how the pointers would move through the buffer.

* * indicates which address the pointer is pointing to.
For the long * :

1. *0x11*, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
2. 0x11, 0x11, 0x11, 0x11, *0x22*, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
3. 0x11, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, *0x33*, 0x33, 0x33, 0x33

for the short * :

1.*0x11*, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
2. 0x11, 0x11, *0x11*, 0x11, 0x22, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
3. 0x11, 0x11, 0x11, 0x11, *0x22*, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
4. 0x11, 0x11, 0x11, 0x11, 0x22, 0x22, *0x22*, 0x22, 0x33, 0x33, 0x33, 0x33
5. 0x11, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, *0x33*, 0x33, 0x33, 0x33
6. 0x11, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, 0x33, 0x33, *0x33*, 0x33

From your output given :

the output is:
0xBFA29F44 --> long 1
0xBFA29F48 --> long 2
0xBFA29F4C --> long 3
0xBFA29F44 --> short 1. Notice this is the same as long 1 because plong and pshort were initially at the start of buff
0xBFA29F46 --> short 2
0xBFA29F48 --> short 3 Same as long 2
0xBFA29F4A --> short 4
0xBFA29F4C --> short 5 Same as long 3
0xBFA29F4E --> short 6

Quote:

---

Originally Posted by DaveH

The only thing you are printing is the value of the pointers, the address they point to.

---

No, look at post #6. /:

Quote:

---

Originally Posted by kroiz

No, look at post #6. /:

---

So the original code you provide was wrong? I was going by that piece of code. I assume that is the code the interviewers gave you. Was it not? Did they want you to print *plong and *pshort? If so, then I stand corrected. But I still think they probably wanted you to show knowledge of what I explained with the movement of the pointers.

Quote:

---

Originally Posted by DaveH

So the original code you provide was wrong? I was going by that piece of code. I assume that is the code the interviewers gave you. Was it not? Did they want you to print *plong and *pshort? If so, then I stand corrected. But I still think they probably wanted you to show knowledge of what I explained with the movement of the pointers.

---

Yes the code in the first post is wrong, it is not what the interviewer game me.
They wanted the print of *plong and *pshort.

and yes in order to solve it correctly I had to know the size of the pointers and how they move and that was part of what they wanted to know.
It just weird to me that they also wanted me to know this thing about hex, that w/o it I could not solve the exercise.

Especially due to the fact that it was not the kind of interview that the interviewer is a technical person that after you finish the test, goes over the test with you to see how you think.
It was a test given to me by a hr lady to check if I can proceed to the next stage.
But whatever, I just wanted to learn from it and go on to the next interview.

Quote:

---

Originally Posted by kroiz

Yes it is, because if you take a long and you put in every byte, a hex number, only with hex you would get a number that looks like all the hex numbers "concatenated". that is just a property of hex.

---

It's not some special property of hex. It boils down to the compatibility between binary and hex -- the logarithm of 16 is divisible by the logarithm of 2. In other words, a whole number of hex digits can be represented by a whole number of binary digits.

Octal is the same way, with each digit of octal being equivalent to 3 binary digits.

There is nothing special about any numbering system, whether it is decimal, octal, hex, binary...

The idea of "hexadecimal math" makes about as much sense as "Australian math."

Quote:

---

Originally Posted by brewbuck

It's not some special property of hex. It boils down to the compatibility between binary and hex -- the logarithm of 16 is divisible by the logarithm of 2. In other words, a whole number of hex digits can be represented by a whole number of binary digits.

Octal is the same way, with each digit of octal being equivalent to 3 binary digits.

There is nothing special about any numbering system, whether it is decimal, octal, hex, binary...

The idea of "hexadecimal math" makes about as much sense as "Australian math."

---

I could say that you are absolutely right but for the sake of argument...
I did not say that hex math, is a subset of math or a superset of math or a different set of math - just that it is math that involves hex. nor did I said that it is a unique property of hex. just a property.

But I do understand it better now thanks to your explanasion.