From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3049 invoked by alias); 8 Sep 2017 18:32:49 -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 2050 invoked by uid 89); 8 Sep 2017 18:32:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy= X-HELO: mailbackend.panix.com X-Gm-Message-State: AHPjjUgw/98pFLLGBABfornxWrnsIx7BcQdbKyCg1aVV4JjySj0w8SWL 0h5mNlZ9tIrd0Zui/u3K85znV1EmPw== X-Google-Smtp-Source: AOwi7QDILyTqGCyRO3D/6mo9ygLyE3Gya40Grnp2pn6rsjyJwVKOl7IuLd+5yE/6PHyEtJvbljsuKH/aPtQ84GSYjAA= X-Received: by 10.202.235.80 with SMTP id j77mr3947865oih.220.1504895564071; Fri, 08 Sep 2017 11:32:44 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20170907224219.12483-1-albert.aribaud@3adev.fr> From: Zack Weinberg Date: Fri, 08 Sep 2017 18:32:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof To: Joseph Myers Cc: "Albert ARIBAUD (3ADEV)" , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-09/txt/msg00399.txt.bz2 On Fri, Sep 8, 2017 at 1:24 PM, Joseph Myers wrote: > On Fri, 8 Sep 2017, Zack Weinberg wrote: > >> 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. This only works if all such structures can be enumerated and forced through a compatibility layer. History indicates that it is not, in fact, possible to enumerate all such structures (the problem case I know about is device-specific ioctl operations, which tend to be created by driver authors who don't realize the need for ABI compatibility shims until it's too late). >> (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 For the reason given above, I confidently predict that there is at least one failure to do this conversion correctly in every released kernel ever. >> 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. I suppose it could be __nsec_t in time.h, but I would prefer to include "and time.h defines nsec_t" in the scope of the willful violation of C11. zw