confused with bytes, blocks, en-/decoding in c++ - c++

Question

I have a 64-byte block and want to append a 64 Bit (8 Byte) Block of data at the end.
typedef unsigned char uint1; // 1 Byte
typedef unsigned int uint4; // 4 Byte
// The 64 Byte-Block:
int BLOCKSIZE=64;
static uint1 padding[BLOCKSIZE] = {
0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};
// [[10000000][00000000].........[00000000]]
// The 64 Bit (8 Byte-Block):
uint4 appendix[2] = {};
appendix[1] = 0x000000ff;
// [[00000000000000000000000000000000][00000000000000000000000011111111]]
after memcpy 8 bytes from appendix to the last 8 byte of padding
memcpy(&padding[56], &appendix, 8);
it looks like
static uint1 padding[BLOCKSIZE] = {
0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0, 0, 0, 0
};
but shouldn't it look like this?
static uint1 padding[BLOCKSIZE] = {
0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff
};
I don't know whats wrong here!?!?
Can you help me?

Answer 1

appendix[1] = 0x000000ff;
// [[00000000000000000000000000000000][00000000000000000000000011111111]]
You're making assumptions about the byte order (endianness). You can't make such assumptions. Depending on byte-order of the architechture, appendix could alternatively be represented like this:
// [[00000000000000000000000000000000][11111111000000000000000000000000]]
If you want to set the last byte specifically, then you need to operate on bytes, not multi-byte integers. Like this for example:
uint1 appendix[8] = {};
appendix[7] = 0xff;
If you indeed need the last 8 bytes to represent two 4 byte integers, your code is correct in that regard and only your assumption about what the memory should look like is wrong.
If the integer must be in a particular byte order for sending it over network, then you must convert it appropriately. POSIX provides htonl and it's sister functions for exactly that. The functions are also provided by msvc.
You're also making the assumption that unsigned int is 4 bytes. It's not guaranteed to be. Use int32_t instead if you need a 4 byte integer.
Update:
My Goal is to implement MD5 and I need to append a 64 bit representation of the length of a file.
According to rfc1321:
... a sequence of
bytes can be interpreted as a sequence of 32-bit words, where each
consecutive group of four bytes is interpreted as a word with the
low-order (least significant) byte given first.
MD5 is little endian. Therefore writing a 2*4 array without converting the byte order will work correctly only on a little endian processor.
I recommend using a 8*1 byte-array so that you can control the order of the bytes exactly as the specification requires. Alternatively, if you're on linux or another platform that provides them, you could use htole32 and le32toh functions to convert to the correct byte order. On another platform you may need to implement them yourself.

Answer 2

So, as far as I'm able to understand the RFC1321 I need a 64 Bit Integer representation of the original message (file) size. The file size is 64 Byte. In a 64 Bit Integer the value 64 is in binary either:
0000000000000000000000000000000000000000000000000000000001000000
or:
0000001000000000000000000000000000000000000000000000000000000000
I have decoding funcitons for both, but i don't know which is right for md5 ?

Answer 3

You should look at Endianless. Your option is big-endian here.