On Thursday 18 February 2016 17:02:25 Ilya Dryomov wrote: > > If we are going to touch this function at all, let's drop all casts and > just add a comment along the lines of "the lack of cast/sign-extension > here is intentional, this function has a counterpart on the server side > which also lacks cast/sign-extension, etc". To someone who is not up > on these subtleties, the __u64 cast is going to be more confusing than > explicit... We certainly a comment, I was just suggesting to add the cast as well. Again, it's not the lack of the cast on the server that is important here, it's whether it gets interpreted as signed or unsigned at the point where the timestamp is actually used for comparison or printing. Let me suggest a comment here: /* * ceph timestamps are unsigned 32-bit starting at 1970, which is * different from a signed 32-bit or 64-bit time_t. On 64-bit * architectures, this gets interpreted as a subset of time_t * in the range from 1970 to 2106. * Machines with a 32-bit time_t will incorrectly interpret the * timestamps with years 2038-2106 as negative numbers in the * 1902-1969 range, until both kernel and glibc are change to * using 64-bit time_t. */ Arnd -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
