Re: [PATCH v5 1/2] Y2038: Add 64-bit time for all architectures

[Paul Eggert <eggert at cs dot ucla dot edu>]

Albert ARIBAUD wrote:

> Regarding the cast, there is no way to reduce the /need/ for casts, as
> we /do/ need one here. What we can do is reduce the number of explicit
> casts

A terminology point: the C Standard uses the word "cast" to describe what you're 
calling an "explicit cast", and it uses the word "conversion" to describe what 
you're calling a "cast". Let's stick to the standard terminology as it makes for 
less confusion.

> But I disagree that the resulting code would be as clear as the one in
> the patch: it would in fact be less clear, because the intent of the
> code would become implicit rather than explicit in two places:

First, in C, casts are more dangerous than other conversions because they allow 
more typos to go unchecked. If you mistakenly cast an integer to a pointer, the 
compiler often does not complain, but if you mistakenly convert an integer to a 
pointer without casting it, the compiler will catch your mistake and report an 
error. For this reason, C casts should not be used unless necessary (and they 
are not necessary here).

Second, the code I proposed is completely obvious. One cannot read code like this:

   type1 x = ...;
   type2 y = x;
   if (y == x) ...

without immediately knowing what's going on.

Third, as you noted, the proposed fits_in_time_t function does a poor job of 
moving common code into a single function. To do a better job we would need 
something like the reduce_to_time_t function of your email. Unfortunately, as 
you noted in a later email, reduce_to_time_t doesn't work because of include 
problems. The exact same thought process went through my head when I wrote my 
review. That is, I thought "fits_in_time_t is a bad helper function, and trying 
to improve it by having a helper function that captures the actual idea won't 
work due to include hassles, so let's just do things directly; it's just as 
clear and it solves the problem better".

So, let's just do things directly; it's just as clear and it solves the problem 
better.