From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110532 invoked by alias); 8 Sep 2017 17:01:12 -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 110494 invoked by uid 89); 8 Sep 2017 17:01:08 -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=reserved, bet X-HELO: mailbackend.panix.com X-Gm-Message-State: AHPjjUjBkQ2DoXkEU+BfjmIq/oy0PPjOm+ds0YxsQ/hU8TV8OxKmoUa5 jUTbUdvNgOyrR0I3PDA3tPKCt9J0Ug== X-Google-Smtp-Source: AOwi7QBKRa9hCnok8J7i9VA4EvkYnCb6MQsLyhFeUmyF4qspGyuNo5KLMVNe4u5S+a5rMyTevFtiBXvoKtgm66SmOvY= X-Received: by 10.202.237.149 with SMTP id l143mr3286301oih.75.1504890064540; Fri, 08 Sep 2017 10:01:04 -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 17:01: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/msg00389.txt.bz2 On Fri, Sep 8, 2017 at 12:43 PM, Joseph Myers wrote: > 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. Hmm, OK. > 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. That's a good point. What I should have said is "before we do this, we should inspect all affected interfaces and see whether any of them are obsolete to the point where we should demote them to compat symbols, at which point they don't need time64 versions". stime is the only one I _know_ falls into that category: withdrawn in XPG3 + completely superseded by newer APIs + niche usage (there are very few programs that need to _set_ the system time, after all) (unfortunately, a lot of the hits on codesearch.debian.net are unrelated use of the same name, to the point where I can't actually tell how many real uses there are, but I would bet any program that still uses it does so only as a fallback-for-legacy-OSes from clock_settime and friends). >> * 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 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. (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.) >> , 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 that header, even if compiled with -std=c89 and no _foo_SOURCE definitions. zw