From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73240 invoked by alias); 20 Jun 2018 16:01:26 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 73228 invoked by uid 89); 20 Jun 2018 16:01:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=stick X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH v5 1/2] Y2038: Add 64-bit time for all architectures To: Albert ARIBAUD Cc: libc-alpha@sourceware.org References: <20180618191443.9926-1-albert.aribaud@3adev.fr> <20180618191443.9926-2-albert.aribaud@3adev.fr> <7c019928-a664-dc58-b143-5b76f9ca0b44@cs.ucla.edu> <20180620080427.08b290f7@athena> From: Paul Eggert Openpgp: preference=signencrypt Message-ID: Date: Wed, 20 Jun 2018 16:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180620080427.08b290f7@athena> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-06/txt/msg00617.txt.bz2 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 y= ou're=20 calling an "explicit cast", and it uses the word "conversion" to describe w= hat=20 you're calling a "cast". Let's stick to the standard terminology as it make= s for=20 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 a= llow=20 more typos to go unchecked. If you mistakenly cast an integer to a pointer,= the=20 compiler often does not complain, but if you mistakenly convert an integer = to a=20 pointer without casting it, the compiler will catch your mistake and report= an=20 error. For this reason, C casts should not be used unless necessary (and th= ey=20 are not necessary here). Second, the code I proposed is completely obvious. One cannot read code lik= e this: type1 x =3D ...; type2 y =3D x; if (y =3D=3D x) ... without immediately knowing what's going on. Third, as you noted, the proposed fits_in_time_t function does a poor job o= f=20 moving common code into a single function. To do a better job we would need= =20 something like the reduce_to_time_t function of your email. Unfortunately, = as=20 you noted in a later email, reduce_to_time_t doesn't work because of includ= e=20 problems. The exact same thought process went through my head when I wrote = my=20 review. That is, I thought "fits_in_time_t is a bad helper function, and tr= ying=20 to improve it by having a helper function that captures the actual idea won= 't=20 work due to include hassles, so let's just do things directly; it's just as= =20 clear and it solves the problem better". So, let's just do things directly; it's just as clear and it solves the pro= blem=20 better.