From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38852 invoked by alias); 8 Sep 2017 19:59:34 -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 38040 invoked by uid 89); 8 Sep 2017 19:59:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*M:92b4, Hx-languages-length:1890, systematic, watch X-HELO: zimbra.cs.ucla.edu Subject: Re: [RFC PATCH 51/52] Y2038: add RPC functions To: "Albert ARIBAUD (3ADEV)" , libc-alpha@sourceware.org References: <20170907224219.12483-50-albert.aribaud@3adev.fr> <20170908174909.28192-1-albert.aribaud@3adev.fr> <20170908174909.28192-2-albert.aribaud@3adev.fr> From: Paul Eggert Message-ID: Date: Fri, 08 Sep 2017 19:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170908174909.28192-2-albert.aribaud@3adev.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-09/txt/msg00405.txt.bz2 On 09/08/2017 10:49 AM, Albert ARIBAUD (3ADEV) wrote: > +CLIENT * > +__clntudp_create64 (struct sockaddr_in *raddr, u_long program, u_long ve= rsion, > + struct __timeval64 wait, int *sockp) > +{ > + struct timeval wait32; > + if (wait.tv_sec > INT_MAX) > + { > + return NULL; > + } > + return clntudp_create (raddr, program, version, wait32, sockp); > +} I'm not seeing how this could work. The code does not copy the value of=20 'wait' to 'wait32'. And the code doesn't have a proper check for fitting=20 in 'int', e.g., it will do the wrong thing for INT_MIN - 1L. And there's=20 no error status set when the time is out of range. I haven't reviewed the patches carefully, just caught this in a spot=20 check. Please look systematically for similar errors. While you're doing that systematic review, I suggest putting something=20 like the following code into a suitable private include file, and using=20 it to tell whether a __time64_t value is in time_t range. This will=20 generate zero instructions when time_t is 64-bit, so generic callers can=20 use this function without needing any ifdefs and without losing any=20 performance on 64-bit time_t platforms. You should write similar static=20 functions for checking whether struct __timeval64 is in struct timeval=20 range, and similarly for struct __timespec64. These can check for the=20 subseconds parts being in range, as needed (watch for x32 here). The=20 idea is to be systematic about this stuff and to do it in one place, to=20 avoid ticky-tack range bugs such as are in the above-quoted code. =C2=A0 /* time_t is always 'long int' in the GNU C Library.=C2=A0 */ =C2=A0 #define TIME_T_MIN LONG_MIN =C2=A0 #define TIME_T_MAX LONG_MAX =C2=A0 static inline bool =C2=A0 fits_in_time_t (__time64_t t) =C2=A0 { =C2=A0 #if 7 <=3D __GNUC__ =C2=A0=C2=A0=C2=A0 return !__builtin_add_overflow_p (t, 0, TIME_T_MAX); =C2=A0 #endif =C2=A0=C2=A0=C2=A0 return TIME_T_MIN <=3D t && t <=3D TIME_T_MAX; =C2=A0 }