From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24128 invoked by alias); 8 Sep 2017 16:43:27 -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 24103 invoked by uid 89); 8 Sep 2017 16:43:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=liaison, Austin, withdrawn, reserved X-HELO: relay1.mentorg.com Date: Fri, 08 Sep 2017 16:43:00 -0000 From: Joseph Myers To: Zack Weinberg CC: "Albert ARIBAUD (3ADEV)" , GNU C Library Subject: Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof In-Reply-To: Message-ID: References: <20170907224219.12483-1-albert.aribaud@3adev.fr> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-09/txt/msg00386.txt.bz2 On Fri, 8 Sep 2017, Zack Weinberg wrote: > * I understand that you are trying to make the transition as seamless > as possible with _TIME_BITS and so on, but I would seriously question > whether it is appropriate to preserve super-legacy APIs such as > 'stime' and 'utime' in the extended mode. (I'd put the cutoff at > 'gettimeofday', which is still heavily used even though > 'clock_gettime' officially supersedes it.) I don't think utime is super-legacy; it's in the 2008 edition of POSIX. Now, stime is not part of any supported standard (it was withdrawn in XPG3) - such old BSD/SVID interfaces that are now in __USE_MISC but no other standard are definitely worth considering for obsoletion (removing declarations / documentation, making into compat symbols not available for new ports / static linking) if there are clear replacements for any current uses / not much current use. And such obsoletion for nonstandard time-related interfaces may well be a useful preliminary to reduce the number of interfaces needing _TIME_BITS=64 versions. (Many such interfaces are of course not time-related but just as deserving of consideration for obsoletion; in general obsoletion of one such interface is independent of obsoletion of any others.) > * The POSIX (and ISO C now, argh) requirement for tv_nsec to be 'long' > is, as discussed at great length earlier, incorrect and should be > ignored. It should instead be a new typedef 'nsec_t' available in And as discussed, I disagree and don't think we should invent any such typedef or deviate from this requirement, given that long is fully able to represent all valid nanoseconds values, in the absence of clear evidence that POSIX and ISO C agree with removing that requirement (e.g. an Austin Group issue tagged issue8 with accepted changes for the next revision of POSIX, combined with acceptance for C2X in WG14 minutes of the issue raised by the Austin Group liaison - or a WG14 change accepted for C2X with agreement on the Austin Group side following the change being passed in the other direction). When the matter was raised with the Austin Group in May 2014, no-one contradicted Rich Felker's comment (which I agree with) that the x32 issue is just a Linux kernel bug which needs to be fixed. (I think this use of long is *less* of an issue than e.g. printf returning int, since you can legitimately print more characters than fit in int.) > , matching the kernel's choice of 32 or 64 bits for this > field (all _t names are reserved for future extension, so the typedef > doesn't need to be _GNU_SOURCE-only). This "willful violation" (as the They are not reserved in ISO C, only in POSIX. -- Joseph S. Myers joseph@codesourcery.com