From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68493 invoked by alias); 8 Sep 2017 17:24:50 -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 68482 invoked by uid 89); 8 Sep 2017 17:24:49 -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=essence, reserved X-HELO: relay1.mentorg.com Date: Fri, 08 Sep 2017 17:24: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/msg00391.txt.bz2 On Fri, 8 Sep 2017, Zack Weinberg wrote: > > 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 > > Neither you, nor Rich, nor anyone else on the cited Austin Group > discussion has addressed the actual issue, which is that this is a > datum embedded in structures passed across the kernel/user boundary by > reference, it is impossible to enumerate all such structures, > therefore its type _must_ be a typedef so that it can be made to match > the kernel's expectations, whatever those might be. I don't see this as in any way an issue for having a definition of struct timespec that conforms to ISO C and POSIX requirements. Code passing data to the kernel knows the structures being used locally and needs to convert it to the kernel's layout, which might be e.g. struct __kernel_timespec64. I don't see that as different in essence from e.g. converting a local-time broken down date/hours/minutes/seconds/nanoseconds value before passing it to the kernel, if that's the form the particular application stores time in. It just so happens that, as an optimization, we can arrange the layout so that we both are POSIX-compatible and do not require any layout conversions between timestamps coming *from* the kernel and struct timespec. > (And I don't particularly see why people seem to think this is an > x32-specific issue. It potentially affects *any* 32-bit ABI on a > 64-bit kernel.) The kernel does the conversion just fine for a pure 32-bit struct timespec - as it does for the entire compat interface - and could do them perfectly well for a structure with 64-bit seconds and 32-bit (+ padding) nanoseconds. It just so happens not to for the very specific case of x32. > >> , 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. > > doesn't exist in ISO C as far as I know, so how could it > be? But any program that uses it opts into POSIX's specification for My point is that you can't expose nsec_t, even as a typedef for long, in for C11. -- Joseph S. Myers joseph@codesourcery.com