Derrick Stolee <stolee@xxxxxxxxx> writes: > + packedDate[0] = htonl((*list)->date >> 32); > + packedDate[1] = htonl((*list)->date); How forward-looking do we want to be? The commit.date field happens to be unsigned so there is no point masking the result of right shifting it, but that would not stay to be the case once we start supporting negative timestamps, for example. Also, I recall that you plan to squeeze generation number in 30 bits or so of one of these words. Wouldn't it mean that higher order bits of commit.date must be masked out anyway, even though we do not have to worry about right shift propagating the sign-bit down? Also, would >>32 be a problem if commit.date is an uint32 (and shifting all its bits out to the right)?
