Please, do not write shift amounts in octal. Or anything else in octal. Mask after shifting, so you can use the same mask. It's less verbose and probably easi

Please, do not write shift amounts in octal. Or anything else in octal. Mask after shifting, so you can use the same mask. It's less verbose and probably easier to optimize, based on the simple pattern that an expression of the form: EXPR & MOD is being converted to a type which is MOD + 1 bits wide. From this: #define WRITE64BE(P, V) \ ((P)[0] = (0xFF00000000000000 & (V)) >> 070, \ (P)[1] = (0x00FF000000000000 & (V)) >> 060, \ (P)[2] = (0x0000FF0000000000 & (V)) >> 050, \ (P)[3] = (0x000000FF00000000 & (V)) >> 040, \ (P)[4] = (0x00000000FF000000 & (V)) >> 030, \ (P)[5] = (0x0000000000FF0000 & (V)) >> 020, \ (P)[6] = (0x000000000000FF00 & (V)) >> 010, \ (P)[7] = (0x00000000000000FF & (V)) >> 000, (P) + 8) To this: #define WRITE64BE(P, V) \ ((P)[0] = ((V) >> 56) & 0xFF, \ (P)[1] = ((V) >> 48) & 0xFF, \ (P)[2] = ((V) >> 40) & 0xFF, \ (P)[3] = ((V) >> 32) & 0xFF, \ (P)[4] = ((V) >> 24) & 0xFF, \ (P)[5] = ((V) >> 16) & 0xFF, \ (P)[6] = ((V) >> 8) & 0xFF, \ (P)[7] = (V) & 0xFF, (P) + 8) It doesn't help anyone that the multiples of 8 look nice in octal, because these decimals are burned into hackers' brains. And are you gonna use base 13 for when multiples of 13 look good? Save the octal for chmod 0777 public-dir. Anyone who doesn't know this leading zero stupidity perpetrated by C reads 070 as "seventy". Even 78, 68, 58, 48, ... would be better, and also take 3 characters: #define WRITE64BE(P, V) \ ((P)[0] = ((V) >> 7*8) & 0xFF, \ (P)[1] = ((V) >> 6*8) & 0xFF, \ (P)[2] = ((V) >> 5*8) & 0xFF, \ (P)[3] = ((V) >> 4*8) & 0xFF, \ (P)[4] = ((V) >> 3*8) & 0xFF, \ (P)[5] = ((V) >> 2*8) & 0xFF, \ (P)[6] = ((V) >> 8) & 0xFF, \ (P)[7] = (V) & 0xFF, (P) + 8) though we are relying on knowing that * has higher precedence than >>. Supplementary note: when we have the 0xFF in this position, and P has type "unsigned char", we can remove it. If P is unsigned char, the & 0xFF does nothing, except on machines where chars are wider than 8 bits. These fall into two categories: historic museum hardware your code will never run on and DSP chips. On DSP chips, bytes wider than 8 doesn't mean 9 or 10, but 16 or more. Simply doing & 0xFF may not make the code work. You may have to pack the code into 16 bit bytes in the right byte order. (Been there and done that. E.g. I worked on an ARM platform that had a TeakLite III DSP, where that sort of thing was done in communicating data between the host and the DSP). So we are actually okay with: #define WRITE64BE(P, V) \ ((P)[0] = (V) >> 56), \ (P)[1] = (V) >> 48), \ (P)[2] = (V) >> 40), \ (P)[3] = (V) >> 32), \ (P)[4] = (V) >> 24), \ (P)[5] = (V) >> 16), \ (P)[6] = (V) >> 8), \ (P)[7] = (V) , (P) + 8)