[{"id":1765000,"web_url":"http://patchwork.ozlabs.org/comment/1765000/","msgid":"","list_archive_url":null,"date":"2017-09-07T23:21:16","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":4349,"url":"http://patchwork.ozlabs.org/api/people/4349/","name":"Joseph Myers","email":"joseph@codesourcery.com"},"content":"General observations on this patch series:\n\n* Nothing should use a GLIBC_Y2038 version. Use GLIBC_2.27 and update as \nnecessary during rebases if this doesn't get into 2.27.\n\n* Nothing should go in architecture-specific files such as \nsysdeps/unix/sysv/linux/arm/Versions. For OS-independent interfaces use \nfiles such as time/Versions - wherever the existing versions of those \ninterfaces for existing time_t are.\n\n* How such a patch series was tested needs to be described in the summary \nof the series. For a series like this, full testsuite runs on multiple \n32-bit and 64-bit architectures as well as use of build-many-glibcs.py to \ndo the compilation tests for (almost) all configurations is important (or \nif a series is a preliminary version with limited architecture support, \nthat should be stated explicitly, but the full testsuite should still pass \non at least one 32-bit and one 64-bit architecture).\n\n* I'd expect lots of extra tests using _TIME_BITS=64 to be added in such a \npatch series, to make sure that every new ABI is covered by the testsuite.\n\n* Documentation of _TIME_BITS is clearly needed.\n\n* You need to make sure that new ABIs are not added / used on platforms \nwhere time_t is already 64-bit.\n\n* All new files need a descriptive first line before the copyright notice.\n\n* All copyright ranges in new files should end with 2017.\n\n* No \"Contributed by\" in new files.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84368-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"cUDXwiuk\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpGg86rs9z9s3w\n\tfor ;\n\tFri, 8 Sep 2017 09:21:40 +1000 (AEST)","(qmail 104906 invoked by alias); 7 Sep 2017 23:21:32 -0000","(qmail 104716 invoked by uid 89); 7 Sep 2017 23:21:32 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; q=dns; s=default; b=E5/mx\n\tzetpR22aya36tl5u6QCbxvTN+uYKSKyVZ3HCf5YdH0+0WXmippMx0Blf4N6MyngE\n\tAx6KUp2T9jTBncCFySbe8VTRH2V89sO9QfprTwVG1Z3lpbAkqIeJWmr5WpIT+Sg1\n\tJ3sU7+iAaHGHSBhiSYj2sva2Jg2/jtenrboAAw=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; s=default; bh=m+L8QdckVD/\n\t+Zo3ivroM+JvEasg=; b=cUDXwiukQsTW5smoiAcuWd3icmywn49l1mzYjhUYqmF\n\t7oi649TSZ9k5f0NhwDGyv8/9Z+WVmG1cof28J95ZbidfIgV9iV2hrlt9Kt3OANCm\n\tGedK00i+faWzYQSsixuGvA8avP01AkpsaebdeEPkZ0bnGToGyH8Kq84UknuZVeO4\n\t=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.0 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=HTo:D*fr,\n\tHx-languages-length:1473","X-HELO":"relay1.mentorg.com","Date":"Thu, 7 Sep 2017 23:21:16 +0000","From":"Joseph Myers ","To":"\"Albert ARIBAUD (3ADEV)\" ","CC":"","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","In-Reply-To":"<20170907224219.12483-1-albert.aribaud@3adev.fr>","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\n\tsvr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)"}},{"id":1765073,"web_url":"http://patchwork.ozlabs.org/comment/1765073/","msgid":"<20170908062302.284f81c1.albert.aribaud@3adev.fr>","list_archive_url":null,"date":"2017-09-08T04:23:02","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":65557,"url":"http://patchwork.ozlabs.org/api/people/65557/","name":"Albert ARIBAUD (3ADEV)","email":"albert.aribaud@3adev.fr"},"content":"On Fri, 8 Sep 2017 00:41:27 +0200, \"Albert ARIBAUD (3ADEV)\"\n wrote :\n\n> This series implements Y2038-proof types, implementation, internal\n> functions, and APIs. For more information, see documentation at\n> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign\n> \n> Each patch in this series except the last add one type or function,\n> with a few exception where several functions are implemented as a whole.\n> \n> The last patch enables the _TIME_BITS mechanism. Once this patch is\n> applied, API header files will will use 64-bit time if _TIME_BITS is\n> defined and equal to 64 prior to their inclusion, and conversively,\n> will use 32-bit time if _TIME_BITS is different from 64 or does not\n> exist.\n\nAdditional info: this RFC patch series only works on ARM, but it should\nbe extended to all 32-bit architectures later.\n\nCordialement,\nAlbert ARIBAUD\n3ADEV","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84371-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"Q5RnOEvi\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpPMD6Gh3z9s76\n\tfor ;\n\tFri, 8 Sep 2017 14:23:20 +1000 (AEST)","(qmail 35765 invoked by alias); 8 Sep 2017 04:23:11 -0000","(qmail 35756 invoked by uid 89); 8 Sep 2017 04:23:11 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\tq=dns; s=default; b=NHgwP9bnERaRI27y8RFf0WlovplIRHPhudW2sWoXXyq\n\toNMikokBoFzdUJXZqfc0qAVFJnMcbswYGt0+GPQ3xzZhx91BLFpzRA4ze8RY/UJ1\n\tbRMcegQnL5AW2XXGbViJU5+0wQDOzMzbaiDGBPMJXgT8BWhVA70TuZHANhslFWvY\n\t=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\ts=default; bh=e6M2biC/jBlhBrGaoEuUF3r3nBs=; b=Q5RnOEviAydA8UHd+\n\tiJt1vGMHSdgjFVMPv2ANuWhLQ6do8iTNE0kYkw19cRP6B7N6FKQ7qcxBokNyF7O4\n\tiGvYI0r9u3rxzrpyDYTbI6O36iaH9UKwje+r5QxTqsnISgmuJxmFIMoowbamvlGO\n\tfVIt30JAjBPObLNwBzQ8tYod3Y=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.6 required=5.0 tests=BAYES_00,\n\tKAM_LAZY_DOMAIN_SECURITY,\n\tRCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=cordialement","X-HELO":"smtp6-g21.free.fr","Date":"Fri, 8 Sep 2017 06:23:02 +0200","From":"Albert ARIBAUD ","To":"libc-alpha@sourceware.org","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","Message-ID":"<20170908062302.284f81c1.albert.aribaud@3adev.fr>","In-Reply-To":"<20170907224219.12483-1-albert.aribaud@3adev.fr>","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit"}},{"id":1765488,"web_url":"http://patchwork.ozlabs.org/comment/1765488/","msgid":"","list_archive_url":null,"date":"2017-09-08T16:19:08","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":65878,"url":"http://patchwork.ozlabs.org/api/people/65878/","name":"Zack Weinberg","email":"zackw@panix.com"},"content":"On Thu, Sep 7, 2017 at 7:21 PM, Joseph Myers wrote:\n> General observations on this patch series:\n\nI concur with all of Joseph's observations and would add:\n\n> * You need to make sure that new ABIs are not added / used on platforms\n> where time_t is already 64-bit.\n\nElaborating on this, when time_t is already 64 bits, defining\n_TIME_BITS=64 should have no effect on the generated code, and\ndefining _TIME_BITS=32 should cause a compile-time error.\n\n* We are not going to land these patches until the kernel side is\nfinalized. All of the places where you have \"// TODO: implement after\nthe kernel does\" must be replaced with an actual implementation.\nLikewise, we need a complete implementation for all supported\narchitectures before landing. You're not on the hook to implement\nthis feature for the Hurd, but you should coordinate with Samuel\nThibault so that at least you do not make glibc-for-Hurd more broken\nthan it already is.\n\n(But I would encourage you to create a named branch in glibc git for\nthis project if you haven't already, to make it easier for others to\nexperiment with it.)\n\n* I understand that you are trying to make the transition as seamless\nas possible with _TIME_BITS and so on, but I would seriously question\nwhether it is appropriate to preserve super-legacy APIs such as\n'stime' and 'utime' in the extended mode. (I'd put the cutoff at\n'gettimeofday', which is still heavily used even though\n'clock_gettime' officially supersedes it.)\n\n* The POSIX (and ISO C now, argh) requirement for tv_nsec to be 'long'\nis, as discussed at great length earlier, incorrect and should be\nignored. It should instead be a new typedef 'nsec_t' available in\n, matching the kernel's choice of 32 or 64 bits for this\nfield (all _t names are reserved for future extension, so the typedef\ndoesn't need to be _GNU_SOURCE-only). This \"willful violation\" (as the\nHTML5 folks put it) must, of course, be documented.\n\n* We do not use Signed-off-by: and we actively want you to _not_\ninclude it in your patch submissions. (We have the FSF-mandated\nactual copyright assignments instead.)\n\n* The patch series is split too finely. I recommend breaking it up by\ntype instead of by function -- time64_t + all the functions that use\nonly time64_t; struct timeval64 + all the functions that use only\ntime64_t and/or struct timeval64; and so on.\n\nzw","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84386-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"FUhWLAt9\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpjFM4G2xz9s7p\n\tfor ;\n\tSat, 9 Sep 2017 02:19:19 +1000 (AEST)","(qmail 120308 invoked by alias); 8 Sep 2017 16:19:13 -0000","(qmail 120299 invoked by uid 89); 8 Sep 2017 16:19:13 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; q=dns; s=default; b=qBrZ\n\tTl3sxnHPlnAKBgppkBkIW7LlUKkbmA69jCbKyoUQxg19x/t1sY7XFcbzJx6DkiUR\n\tH8clramUa9OA60G4cFrDtlXguWdILBZ0IWbw56FVogv5hR7XyXG4XpnKcsmlaxO4\n\tkV2NGIQ114u6wSXkC1/vPj9jhNm5JYV2LAKxYTQ=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; s=default; bh=MYz5tCZKnU\n\tFTAQzNsun9IGyriuw=; b=FUhWLAt9WdkprG+3RaY9AV/F8fOqrycFT5+//PC0OT\n\th/1QS8rFZrjkIy13a5nUNfh0jC8Kb3kEVKv2uwul+dJGbTn7sczyoJRoK9JZctm/\n\tB1aNN1Il1q0COZvR2D6rmKrWwJixRmxDvi9QTGEoi/M5Xa6FKwE2IvBXgMjyh9fs\n\tg=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.4 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_SORBS_SPAM, RP_MATCHES_RCVD, SPF_PASS,\n\tURIBL_RED autolearn=no version=3.3.2 spammy=submissions,\n\treserved, recommend, seamless","X-HELO":"mailbackend.panix.com","X-Gm-Message-State":"AHPjjUj+3HxJK8ygWP36PEl5ETR2+K997NPRrmVOHKsXSB4nauD1Wzvc\n\tTHYl3MJ6FBfcrGy3lihcfnbTKgk+WA==","X-Google-Smtp-Source":"AOwi7QAMbAHkGgkGzFt2uFXy7h9V7Iw/26bM0OZr1KOPtJYI6Yks7Mcl433K95xoLr8wu0nNkXSbrFlx3NnyTPOfZcU=","X-Received":"by 10.202.75.133 with SMTP id y127mr3856075oia.287.1504887549381;\n\tFri, 08 Sep 2017 09:19:09 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t","From":"Zack Weinberg ","Date":"Fri, 8 Sep 2017 12:19:08 -0400","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","To":"Joseph Myers ","Cc":"\"Albert ARIBAUD (3ADEV)\" ,\n\tGNU C Library ","Content-Type":"text/plain; charset=\"UTF-8\""}},{"id":1765505,"web_url":"http://patchwork.ozlabs.org/comment/1765505/","msgid":"","list_archive_url":null,"date":"2017-09-08T16:43:14","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":4349,"url":"http://patchwork.ozlabs.org/api/people/4349/","name":"Joseph Myers","email":"joseph@codesourcery.com"},"content":"On Fri, 8 Sep 2017, Zack Weinberg wrote:\n\n> * I understand that you are trying to make the transition as seamless\n> as possible with _TIME_BITS and so on, but I would seriously question\n> whether it is appropriate to preserve super-legacy APIs such as\n> 'stime' and 'utime' in the extended mode. (I'd put the cutoff at\n> 'gettimeofday', which is still heavily used even though\n> 'clock_gettime' officially supersedes it.)\n\nI don't think utime is super-legacy; it's in the 2008 edition of POSIX. \nNow, stime is not part of any supported standard (it was withdrawn in \nXPG3) - such old BSD/SVID interfaces that are now in __USE_MISC but no \nother standard are definitely worth considering for obsoletion (removing \ndeclarations / documentation, making into compat symbols not available for \nnew ports / static linking) if there are clear replacements for any \ncurrent uses / not much current use. And such obsoletion for nonstandard \ntime-related interfaces may well be a useful preliminary to reduce the \nnumber of interfaces needing _TIME_BITS=64 versions. (Many such \ninterfaces are of course not time-related but just as deserving of \nconsideration for obsoletion; in general obsoletion of one such interface \nis independent of obsoletion of any others.)\n\n> * The POSIX (and ISO C now, argh) requirement for tv_nsec to be 'long'\n> is, as discussed at great length earlier, incorrect and should be\n> ignored. It should instead be a new typedef 'nsec_t' available in\n\nAnd as discussed, I disagree and don't think we should invent any such \ntypedef or deviate from this requirement, given that long is fully able to \nrepresent all valid nanoseconds values, in the absence of clear evidence \nthat POSIX and ISO C agree with removing that requirement (e.g. an Austin \nGroup issue tagged issue8 with accepted changes for the next revision of \nPOSIX, combined with acceptance for C2X in WG14 minutes of the issue \nraised by the Austin Group liaison - or a WG14 change accepted for C2X \nwith agreement on the Austin Group side following the change being passed \nin the other direction). When the matter was raised with the Austin Group \nin May 2014, no-one contradicted Rich Felker's comment (which I agree \nwith) that the x32 issue is just a Linux kernel bug which needs to be \nfixed. (I think this use of long is *less* of an issue than e.g. printf \nreturning int, since you can legitimately print more characters than fit \nin int.)\n\n> , matching the kernel's choice of 32 or 64 bits for this\n> field (all _t names are reserved for future extension, so the typedef\n> doesn't need to be _GNU_SOURCE-only). This \"willful violation\" (as the\n\nThey are not reserved in ISO C, only in POSIX.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84388-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"EaqUcsoy\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpjnK6gMcz9s76\n\tfor ;\n\tSat, 9 Sep 2017 02:43:33 +1000 (AEST)","(qmail 24128 invoked by alias); 8 Sep 2017 16:43:27 -0000","(qmail 24103 invoked by uid 89); 8 Sep 2017 16:43:27 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; q=dns; s=default; b=W3dG/\n\t/mJHZ67TEEWwIrAhBWD6B6pPbqM6qEW340Z7uzy8aKJd6+dG+VJJR7PhT9sxt2C7\n\tMoMhJ8E34e7fSkGD0lIqhkxda2Ngn1MCUnZVlhAVKbDdMEunnkzo4nm01SoNf6DI\n\tPwJTcBjktUtny5zQNUB/X3JzKUXuBa8LTCMZZA=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; s=default; bh=PKRiZKD7ZRm\n\trraiu/D5k74/zODs=; b=EaqUcsoyfuPCvR1hl9fliC2UrhaXVWvWCsgyGODZo19\n\t5QDYd3GGfyNOnq8PLLe2zF4HQqHXgXMOoTtW1YTlmGgsLgYjuesdGP14sbFJP4DP\n\ttZw0Qj66YNuXFt4GjPpYShbZEOFVuwXH7ytubmyxWhkhVM+t+cIG+HDkMSxjAaqk\n\t=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.0 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=liaison, Austin,\n\twithdrawn, reserved","X-HELO":"relay1.mentorg.com","Date":"Fri, 8 Sep 2017 16:43:14 +0000","From":"Joseph Myers ","To":"Zack Weinberg ","CC":"\"Albert ARIBAUD (3ADEV)\" , GNU C Library\n\t","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","In-Reply-To":"","Message-ID":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t","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\n\tsvr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)"}},{"id":1765519,"web_url":"http://patchwork.ozlabs.org/comment/1765519/","msgid":"<95f9294b-49d8-267b-d810-ffe7f33a2102@cs.ucla.edu>","list_archive_url":null,"date":"2017-09-08T16:53:55","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":4434,"url":"http://patchwork.ozlabs.org/api/people/4434/","name":"Paul Eggert","email":"eggert@CS.UCLA.EDU"},"content":"On 09/08/2017 09:43 AM, Joseph Myers wrote:\n> (I think this use of long is*less* of an issue than e.g. printf\n> returning int, since you can legitimately print more characters than fit\n> in int.)\n\nprintf is obviously more-important since it's used all over the place \nand is more likely to run into the arbitrary int limit. That being said, \nin practice GNU Coreutils, GNU Emacs, and other application code that I \nhelp maintain long ago stopped assuming the POSIX requirement that \ntv_nsec must be of type 'long', precisely because we want to be portable \nto x32. So from my point of view this ship already sailed and the POSIX \nrequirement is no longer helpful; on the contrary, it is misleading \nprogrammers who are trying to write portable software.\n\nIf the issue is raised again at the Austin Group level, please let us \nknow. I at least would like to put in my two cents.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84389-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"OTlJIlf7\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpk1V14mgz9s7h\n\tfor ;\n\tSat, 9 Sep 2017 02:54:05 +1000 (AEST)","(qmail 102177 invoked by alias); 8 Sep 2017 16:54:00 -0000","(qmail 102147 invoked by uid 89); 8 Sep 2017 16:53:59 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=gWYHIVTCNE0/UsX8\n\t9j9U6zpMXD4lpRKf21zKyYcn+gycBAHgMkOxCHIEeDeJ42LPAfKwv90kD2ltOhrc\n\te6dm4GBjqxuiZt5DR+7lMu55bmy9FL1UaIrBCBMP355WPjt8GJT1yguaHubNqlXA\n\t8utZjtVOzzmifewWN9IVhKPmx5g=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=HmAdQyxi7/6LTsywp/atte\n\ti5Jj8=; b=OTlJIlf7ZYFW95Ji1gyU7pDLFSrQlSSWDgBFBu+KCJhrCjE46+EldC\n\t/AnhsVbBneOhEag3RtelVwWGaYZMOr4y7ieamnUKCNBs3VPaxQ/07YARBPe24YOB\n\tMvuyWB1yhBw1jyfslZUkqmPZMW/9iQrbhL6zSaoGhLyOhtmfKAjg8=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.1 required=5.0 tests=AWL, BAYES_00,\n\tRP_MATCHES_RCVD,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=cents, coreutils","X-HELO":"zimbra.cs.ucla.edu","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","To":"Joseph Myers , Zack Weinberg ","Cc":"\"Albert ARIBAUD (3ADEV)\" ,\n\tGNU C Library ","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t\n\t","From":"Paul Eggert ","Message-ID":"<95f9294b-49d8-267b-d810-ffe7f33a2102@cs.ucla.edu>","Date":"Fri, 8 Sep 2017 09:53:55 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"7bit"}},{"id":1765523,"web_url":"http://patchwork.ozlabs.org/comment/1765523/","msgid":"","list_archive_url":null,"date":"2017-09-08T17:01:03","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":65878,"url":"http://patchwork.ozlabs.org/api/people/65878/","name":"Zack Weinberg","email":"zackw@panix.com"},"content":"On Fri, Sep 8, 2017 at 12:43 PM, Joseph Myers wrote:\n> On Fri, 8 Sep 2017, Zack Weinberg wrote:\n>> * I understand that you are trying to make the transition as seamless\n>> as possible with _TIME_BITS and so on, but I would seriously question\n>> whether it is appropriate to preserve super-legacy APIs such as\n>> 'stime' and 'utime' in the extended mode. (I'd put the cutoff at\n>> 'gettimeofday', which is still heavily used even though\n>> 'clock_gettime' officially supersedes it.)\n>\n> I don't think utime is super-legacy; it's in the 2008 edition of POSIX.\n\nHmm, OK.\n\n> Now, stime is not part of any supported standard (it was withdrawn in\n> XPG3) - such old BSD/SVID interfaces that are now in __USE_MISC but no\n> other standard are definitely worth considering for obsoletion (removing\n> declarations / documentation, making into compat symbols not available for\n> new ports / static linking) if there are clear replacements for any\n> current uses / not much current use.\n\nThat's a good point. What I should have said is \"before we do this,\nwe should inspect all affected interfaces and see whether any of them\nare obsolete to the point where we should demote them to compat\nsymbols, at which point they don't need time64 versions\".\n\nstime is the only one I _know_ falls into that category: withdrawn in\nXPG3 + completely superseded by newer APIs + niche usage (there are\nvery few programs that need to _set_ the system time, after all)\n(unfortunately, a lot of the hits on codesearch.debian.net are\nunrelated use of the same name, to the point where I can't actually\ntell how many real uses there are, but I would bet any program that\nstill uses it does so only as a fallback-for-legacy-OSes from\nclock_settime and friends).\n\n>> * The POSIX (and ISO C now, argh) requirement for tv_nsec to be 'long'\n>> is, as discussed at great length earlier, incorrect and should be\n>> ignored. It should instead be a new typedef 'nsec_t' available in\n>\n> And as discussed, I disagree and don't think we should invent any such\n> typedef or deviate from this requirement, given that long is fully able to\n> represent all valid nanoseconds values\n\nNeither you, nor Rich, nor anyone else on the cited Austin Group\ndiscussion has addressed the actual issue, which is that this is a\ndatum embedded in structures passed across the kernel/user boundary by\nreference, it is impossible to enumerate all such structures,\ntherefore its type _must_ be a typedef so that it can be made to match\nthe kernel's expectations, whatever those might be.\n\n(And I don't particularly see why people seem to think this is an\nx32-specific issue. It potentially affects *any* 32-bit ABI on a\n64-bit kernel.)\n\n>> , matching the kernel's choice of 32 or 64 bits for this\n>> field (all _t names are reserved for future extension, so the typedef\n>> doesn't need to be _GNU_SOURCE-only). This \"willful violation\" (as the\n>\n> They are not reserved in ISO C, only in POSIX.\n\n doesn't exist in ISO C as far as I know, so how could it\nbe? But any program that uses it opts into POSIX's specification for\nthat header, even if compiled with -std=c89 and no _foo_SOURCE\ndefinitions.\n\nzw","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84391-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"cO4SsV61\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpk9p3HyRz9ryv\n\tfor ;\n\tSat, 9 Sep 2017 03:01:18 +1000 (AEST)","(qmail 110532 invoked by alias); 8 Sep 2017 17:01:12 -0000","(qmail 110494 invoked by uid 89); 8 Sep 2017 17:01:08 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; q=dns; s=default; b=NP5h\n\taqBEpZXNkMsuOfVeGtZKiJOEc0QvVJCRU1vnVaOAxBcHmeM0fRhFmOkFQr7Rlpee\n\tmF0AhvjTQSkqlVY5BiKYZ6WIYVlzc1RT98rQLC+j/Vxr/z+YiruKOuCywgm0qMdt\n\tOsgCRjhmB4n+1T2XtaKGcGthNjz+lKMcL7mikEM=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; s=default; bh=opjvJ0EMlu\n\tRAqdiaIEI5ZyYMdYQ=; b=cO4SsV61JSQUs8s1RWU3RlSrn5GBNzn4rKbZG7SGQH\n\tEct4fcMnrYwROCNDczdDDKju1vnB1wozxdUTofImJf1EtvO50luPy1KDTw3+zSsy\n\t1jjcpf0uVys0VRTnKuT27rSrb04WPVNxnbzCUdF7fIL1aIM2yDUz7iIGBnCPI9B9\n\tk=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.4 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_SORBS_SPAM, RP_MATCHES_RCVD, SPF_PASS,\n\tURIBL_RED autolearn=no version=3.3.2 spammy=reserved, bet","X-HELO":"mailbackend.panix.com","X-Gm-Message-State":"AHPjjUjBkQ2DoXkEU+BfjmIq/oy0PPjOm+ds0YxsQ/hU8TV8OxKmoUa5\n\tjUTbUdvNgOyrR0I3PDA3tPKCt9J0Ug==","X-Google-Smtp-Source":"AOwi7QBKRa9hCnok8J7i9VA4EvkYnCb6MQsLyhFeUmyF4qspGyuNo5KLMVNe4u5S+a5rMyTevFtiBXvoKtgm66SmOvY=","X-Received":"by 10.202.237.149 with SMTP id l143mr3286301oih.75.1504890064540;\n\tFri, 08 Sep 2017 10:01:04 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t\n\t","From":"Zack Weinberg ","Date":"Fri, 8 Sep 2017 13:01:03 -0400","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","To":"Joseph Myers ","Cc":"\"Albert ARIBAUD (3ADEV)\" ,\n\tGNU C Library ","Content-Type":"text/plain; charset=\"UTF-8\""}},{"id":1765526,"web_url":"http://patchwork.ozlabs.org/comment/1765526/","msgid":"<20170908190832.03476c79.albert.aribaud@3adev.fr>","list_archive_url":null,"date":"2017-09-08T17:08:32","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":65557,"url":"http://patchwork.ozlabs.org/api/people/65557/","name":"Albert ARIBAUD (3ADEV)","email":"albert.aribaud@3adev.fr"},"content":"Hi Joseph,\n\nOn Thu, 7 Sep 2017 23:21:16 +0000, Joseph Myers\n wrote :\n\n> General observations on this patch series:\n> \n> * Nothing should use a GLIBC_Y2038 version. Use GLIBC_2.27 and update as \n> necessary during rebases if this doesn't get into 2.27.\n\nUnderstood, will do.\n\n> * Nothing should go in architecture-specific files such as \n> sysdeps/unix/sysv/linux/arm/Versions. For OS-independent interfaces\n> use files such as time/Versions - wherever the existing versions of\n> those interfaces for existing time_t are.\n\nWill do.\n\n> * How such a patch series was tested needs to be described in the summary \n> of the series. For a series like this, full testsuite runs on multiple \n> 32-bit and 64-bit architectures as well as use of build-many-glibcs.py to \n> do the compilation tests for (almost) all configurations is important (or \n> if a series is a preliminary version with limited architecture support, \n> that should be stated explicitly, but the full testsuite should still pass \n> on at least one 32-bit and one 64-bit architecture).\n\nWill do. Right now, the patches are tested using an ad hoc system (as\nstated in the cover letter). I'll run the GLIBC test suite and add\nresults to the cover letter in the next patcxh series iteration.\n\n> * I'd expect lots of extra tests using _TIME_BITS=64 to be added in such a \n> patch series, to make sure that every new ABI is covered by the testsuite.\n\nIndeed.\n\n> * Documentation of _TIME_BITS is clearly needed.\n\nWhere should this documentation go?\n\n> * You need to make sure that new ABIs are not added / used on platforms \n> where time_t is already 64-bit.\n\nWill do.\n\n\n> * All new files need a descriptive first line before the copyright notice.\n\nUnderstood.\n\n> * All copyright ranges in new files should end with 2017.\n\nWill fix.\n\n> * No \"Contributed by\" in new files.\n\nWill fix.\n\nThanks for your feedback!\n\nCordialement,\nAlbert ARIBAUD\n3ADEV","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84392-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"UsWV0SRV\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpkLQ69Rnz9ryv\n\tfor ;\n\tSat, 9 Sep 2017 03:08:46 +1000 (AEST)","(qmail 38268 invoked by alias); 8 Sep 2017 17:08:41 -0000","(qmail 38256 invoked by uid 89); 8 Sep 2017 17:08:40 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\tq=dns; s=default; b=gvgShv2ZZk48qUa9i45DUxIuZLD4O3+pk3DIfQOk3nP\n\tCnegNCADFoBfztpBlPFj5NIKuLZNrKgWiiTagUML8CSHxc9e3VPOQXZDHDJ7hZpD\n\tpLdCEAXLCwnSzJDdbmqDDilQoRqrr6vTmhsWeM06yKjFR0AE9Y/TmMtCOJvr4kqY\n\t=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\ts=default; bh=Svdo5b98xy9lj+Y1JbtpNesLoQ4=; b=UsWV0SRVresQ4chSt\n\t+STCz/PpNRlQYktAfK8YrD6WFoCyd6tHsy5tQZryG2vvXHb3hbN1ETbiaJ8IOIAd\n\tJ9regAZmygtIRIbPtpHro0l7+4xu1BzMU0mY2/M+FQem1XO4rKwJGbsYIPOecYey\n\tnhtewrFHLdR3PvU98xZvDMjUqU=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.6 required=5.0 tests=BAYES_00,\n\tKAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW,\n\tURIBL_RED autolearn=no version=3.3.2 spammy=letter","X-HELO":"smtp6-g21.free.fr","Date":"Fri, 8 Sep 2017 19:08:32 +0200","From":"Albert ARIBAUD ","To":"Joseph Myers ","Cc":"","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","Message-ID":"<20170908190832.03476c79.albert.aribaud@3adev.fr>","In-Reply-To":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit"}},{"id":1765536,"web_url":"http://patchwork.ozlabs.org/comment/1765536/","msgid":"","list_archive_url":null,"date":"2017-09-08T17:24:39","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":4349,"url":"http://patchwork.ozlabs.org/api/people/4349/","name":"Joseph Myers","email":"joseph@codesourcery.com"},"content":"On Fri, 8 Sep 2017, Zack Weinberg wrote:\n\n> > And as discussed, I disagree and don't think we should invent any such\n> > typedef or deviate from this requirement, given that long is fully able to\n> > represent all valid nanoseconds values\n> \n> Neither you, nor Rich, nor anyone else on the cited Austin Group\n> discussion has addressed the actual issue, which is that this is a\n> datum embedded in structures passed across the kernel/user boundary by\n> reference, it is impossible to enumerate all such structures,\n> therefore its type _must_ be a typedef so that it can be made to match\n> the kernel's expectations, whatever those might be.\n\nI don't see this as in any way an issue for having a definition of struct \ntimespec that conforms to ISO C and POSIX requirements. Code passing data \nto the kernel knows the structures being used locally and needs to convert \nit to the kernel's layout, which might be e.g. struct __kernel_timespec64. \nI don't see that as different in essence from e.g. converting a local-time \nbroken down date/hours/minutes/seconds/nanoseconds value before passing it \nto the kernel, if that's the form the particular application stores time \nin. It just so happens that, as an optimization, we can arrange the \nlayout so that we both are POSIX-compatible and do not require any layout \nconversions between timestamps coming *from* the kernel and struct \ntimespec.\n\n> (And I don't particularly see why people seem to think this is an\n> x32-specific issue. It potentially affects *any* 32-bit ABI on a\n> 64-bit kernel.)\n\nThe kernel does the conversion just fine for a pure 32-bit struct timespec \n- as it does for the entire compat interface - and could do them perfectly \nwell for a structure with 64-bit seconds and 32-bit (+ padding) \nnanoseconds. It just so happens not to for the very specific case of x32.\n\n> >> , matching the kernel's choice of 32 or 64 bits for this\n> >> field (all _t names are reserved for future extension, so the typedef\n> >> doesn't need to be _GNU_SOURCE-only). This \"willful violation\" (as the\n> >\n> > They are not reserved in ISO C, only in POSIX.\n> \n> doesn't exist in ISO C as far as I know, so how could it\n> be? But any program that uses it opts into POSIX's specification for\n\nMy point is that you can't expose nsec_t, even as a typedef for long, in \n for C11.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84393-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"dQnuTZdt\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpkj66zR8z9s8J\n\tfor ;\n\tSat, 9 Sep 2017 03:24:58 +1000 (AEST)","(qmail 68493 invoked by alias); 8 Sep 2017 17:24:50 -0000","(qmail 68482 invoked by uid 89); 8 Sep 2017 17:24:49 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; q=dns; s=default; b=Irw6u\n\tePgjgKr3WB6rtYSbdwx4+j5LJY4wgj+z2/OatFx3f5n8+ni5+aVRkqb8CFWQ5cOA\n\tj1KpoEldftiWuZ6UTI8B3iZXcFbUveS5vwxTIkZo/AzgQmhmlJn4HNxnQm+GQo0a\n\tzuJvSJsnVXWs83yo838hsO/my/gvCte3mSa1wU=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; s=default; bh=Yu9jKws3g9c\n\teolMyBVKrjtCusFE=; b=dQnuTZdtYSNNcGuccfSskB/wYApHQnte6Hp+4C00DcR\n\t98ghzPdTfTurubdhR5dhSyiMrCoG68U1IiWgEWy7zlDvHoJYKayNA1mcrBGWSg/9\n\tED1NXvvH13PIZnYxvC/jTwOBVrPY3ogs8Y0V9o1C/CowU1Fik9LVHAT14qcoFzMM\n\t=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.0 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=essence, reserved","X-HELO":"relay1.mentorg.com","Date":"Fri, 8 Sep 2017 17:24:39 +0000","From":"Joseph Myers ","To":"Zack Weinberg ","CC":"\"Albert ARIBAUD (3ADEV)\" , GNU C Library\n\t","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","In-Reply-To":"","Message-ID":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t\n\t\n\t","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\n\tsvr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)"}},{"id":1765537,"web_url":"http://patchwork.ozlabs.org/comment/1765537/","msgid":"","list_archive_url":null,"date":"2017-09-08T17:26:26","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":4349,"url":"http://patchwork.ozlabs.org/api/people/4349/","name":"Joseph Myers","email":"joseph@codesourcery.com"},"content":"On Fri, 8 Sep 2017, Albert ARIBAUD wrote:\n\n> > * Documentation of _TIME_BITS is clearly needed.\n> \n> Where should this documentation go?\n\nIn manual/creature.texi, alongside the documentation of _FILE_OFFSET_BITS.\n\n(It occurred to me that patches 50-52 don't seem to have reached the \nmailing list, so I don't know what was in them.)","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84394-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"T1mZG6/V\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpkl73jlnz9sBW\n\tfor ;\n\tSat, 9 Sep 2017 03:26:43 +1000 (AEST)","(qmail 70947 invoked by alias); 8 Sep 2017 17:26:36 -0000","(qmail 70937 invoked by uid 89); 8 Sep 2017 17:26:35 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; q=dns; s=default; b=fVVYW\n\tIAdI0R/1+OLXlIvDHEq8YTV3c+ByAZ5dlqWG/YVyhjiwkb1Pi0NaFgkbgD4L1e4V\n\tSINpWHIDBrdXa2BeGIdxSfhOeTiaJ5/blJmTg35cQHs/UE4Lvl1818yKGIBvV1P2\n\tEuuxG1ObZHuY46X/50nMUhqCu1kz4AmpyaECtw=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; s=default; bh=LeoE8WQNRD5\n\tfNMQfMXmpSfXi6UY=; b=T1mZG6/VATfKCn3yj1fbdAoEUnBcPlmSCB4S4UwM3fg\n\twktzJF/xmqL3dHeo7Z/e5wbnafErkf/mvam+hSm4u8cRSg/tKa+S8GyLS2CvDNSK\n\tJd58bG51Ft093NVgocFWTNuqZ8S0rDEI9NhOoKNE36KiADrblXTBmbYGVnVXY0uI\n\t=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.0 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=","X-HELO":"relay1.mentorg.com","Date":"Fri, 8 Sep 2017 17:26:26 +0000","From":"Joseph Myers ","To":"Albert ARIBAUD ","CC":"","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","In-Reply-To":"<20170908190832.03476c79.albert.aribaud@3adev.fr>","Message-ID":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t<20170908190832.03476c79.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\n\tsvr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)"}},{"id":1765545,"web_url":"http://patchwork.ozlabs.org/comment/1765545/","msgid":"<20170908194154.49d5c670.albert.aribaud@3adev.fr>","list_archive_url":null,"date":"2017-09-08T17:41:54","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":65557,"url":"http://patchwork.ozlabs.org/api/people/65557/","name":"Albert ARIBAUD (3ADEV)","email":"albert.aribaud@3adev.fr"},"content":"Hi Zack,\n\nOn Fri, 8 Sep 2017 12:19:08 -0400, Zack Weinberg \nwrote :\n\n> On Thu, Sep 7, 2017 at 7:21 PM, Joseph Myers wrote:\n> > General observations on this patch series: \n> \n> I concur with all of Joseph's observations and would add:\n> \n> > * You need to make sure that new ABIs are not added / used on platforms\n> > where time_t is already 64-bit. \n> \n> Elaborating on this, when time_t is already 64 bits, defining\n> _TIME_BITS=64 should have no effect on the generated code, and\n> defining _TIME_BITS=32 should cause a compile-time error.\n\nWill add.\n\n> * We are not going to land these patches until the kernel side is\n> finalized. All of the places where you have \"// TODO: implement after\n> the kernel does\" must be replaced with an actual implementation.\n> Likewise, we need a complete implementation for all supported\n> architectures before landing. You're not on the hook to implement\n> this feature for the Hurd, but you should coordinate with Samuel\n> Thibault so that at least you do not make glibc-for-Hurd more broken\n> than it already is.\n\nRegarding whether the patches should land only once the kernel is\nY0238-safe: these patches are intended to run even on a current and thus\ncompletely Y2038-unsafe kernel, in which case they use 64-bit-time on\nuser side (to make applications compiled with _TIME_BITS==64 happy at\nleast until Y2038 happens) and 32-bit time on kernel side. So I don't\nsee why these patches should wait for a Y2038-safe kernel per se.\n\nRe the TODOs: note that right now, all these TODOs are coded in such a\nway that the implementation \"falls through\" to using 32-bit syscalls or\ncode, just like it would if running on an older kernel.\n\n> (But I would encourage you to create a named branch in glibc git for\n> this project if you haven't already, to make it easier for others to\n> experiment with it.)\n\nThere is such a branch, mentioned in the implementation part of the\nhttps://sourceware.org/glibc/wiki/Y2038ProofnessDesign document.\n\n> * I understand that you are trying to make the transition as seamless\n> as possible with _TIME_BITS and so on, but I would seriously question\n> whether it is appropriate to preserve super-legacy APIs such as\n> 'stime' and 'utime' in the extended mode. (I'd put the cutoff at\n> 'gettimeofday', which is still heavily used even though\n> 'clock_gettime' officially supersedes it.)\n\nI'm all for not adding 64-bit-time versions of APIs which are obsolete.\nThe patch series is organized to facilitate removing or adding types and\nfunctions.\n\nAs to which APIs should be made obsolete, there appears to be room for\ndebate.\n\nI will add a section in the design document listing obsolete(d) APIs\n(there are a few which are tagged as such, but not in a section of\ntheir own yet) and as consensus emerges, I will update the patch series\nand document.\n\n> * The POSIX (and ISO C now, argh) requirement for tv_nsec to be 'long'\n> is, as discussed at great length earlier, incorrect and should be\n> ignored. It should instead be a new typedef 'nsec_t' available in\n> , matching the kernel's choice of 32 or 64 bits for this\n> field (all _t names are reserved for future extension, so the typedef\n> doesn't need to be _GNU_SOURCE-only). This \"willful violation\" (as the\n> HTML5 folks put it) must, of course, be documented.\n\n(seems to be a topic for debate)\n\n> * We do not use Signed-off-by: and we actively want you to _not_\n> include it in your patch submissions. (We have the FSF-mandated\n> actual copyright assignments instead.)\n\nWill fix.\n\n> * The patch series is split too finely. I recommend breaking it up by\n> type instead of by function -- time64_t + all the functions that use\n> only time64_t; struct timeval64 + all the functions that use only\n> time64_t and/or struct timeval64; and so on.\n\nAs indicated above, I broke it up by type and function (except when\ndependencies made it really impractical) to easy adding or removing (and\nreviewing) individual functions. 50-odd patches are manageable IMO, but\nmaybe some people may be put off by it... What I'll do is keep two\nbranches: this fine-grained one, and a coarser-grained one where all\nchanges related to one type are grouped. Best of both worlds.\n\n> zw\n\nThanks for your review!\n\nCordialement,\nAlbert ARIBAUD\n3ADEV","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84395-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"ZkhJrWqm\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpl512PG6z9rxm\n\tfor ;\n\tSat, 9 Sep 2017 03:42:13 +1000 (AEST)","(qmail 75517 invoked by alias); 8 Sep 2017 17:42:05 -0000","(qmail 74303 invoked by uid 89); 8 Sep 2017 17:42:04 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\tq=dns; s=default; b=O7/IGxpUIvWH2INFHNROESGCFljDqlu8KZGqd0LY8GQ\n\t9uEvTJCOEEmHA7Ij+z0xiuYCvZbtLIXD8hHtPVk3LA+lDFf/IYKz2psmhesUKet+\n\tPXHnXDZnfAWYH8XB4qs3SaG8DyFv77wsbqx4NCL1h+6yKxtKpuGjoSDmQSgnD3Sw\n\t=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\ts=default; bh=bADOI1bfZE0BZtkCsZcSCx51tpg=; b=ZkhJrWqmmaNkEPFcA\n\tbAUnqQl12Js4Fpa69r4302eGLtL+QXXoQC+xavCiT6k5yNWkiCBNGzZitogBr0lr\n\tbTAznz90fxWpGqhXebQlDfzeawr8Q99JhNRp476YO6UZxwI40iYRXuwy47X37Xro\n\t9iHqf1ZHQNUoBIwwiUWoNYYlfY=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.6 required=5.0 tests=BAYES_00,\n\tKAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW,\n\tURIBL_RED autolearn=no version=3.3.2 spammy=","X-HELO":"smtp6-g21.free.fr","Date":"Fri, 8 Sep 2017 19:41:54 +0200","From":"Albert ARIBAUD ","To":"Zack Weinberg ","Cc":"Joseph Myers , GNU C Library\n\t","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","Message-ID":"<20170908194154.49d5c670.albert.aribaud@3adev.fr>","In-Reply-To":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit"}},{"id":1765555,"web_url":"http://patchwork.ozlabs.org/comment/1765555/","msgid":"","list_archive_url":null,"date":"2017-09-08T17:59:00","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":4349,"url":"http://patchwork.ozlabs.org/api/people/4349/","name":"Joseph Myers","email":"joseph@codesourcery.com"},"content":"On Fri, 8 Sep 2017, Albert ARIBAUD wrote:\n\n> Regarding whether the patches should land only once the kernel is\n> Y0238-safe: these patches are intended to run even on a current and thus\n> completely Y2038-unsafe kernel, in which case they use 64-bit-time on\n> user side (to make applications compiled with _TIME_BITS==64 happy at\n> least until Y2038 happens) and 32-bit time on kernel side. So I don't\n> see why these patches should wait for a Y2038-safe kernel per se.\n\nWhere the kernel layouts of structures are suitable for use by glibc, we'd \nlike to avoid translation layers. E.g., we need to know what the kernel's \nstruct stat64 variant for 64-bit time_t will look like to ensure no \ntranslation layer is needed. (If the answer is that statx is the \ninterface that should be used for 64-bit times in struct stat so the \nkernel doesn't need to define such a stat64 variant, then the translation \nlayer is needed anyway and we should maybe use the asm-generic 64-bit \nstruct stat variant of the layout on all 32-bit platforms.)","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84399-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"uu3JwgS6\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xplSh72K2z9ryk\n\tfor ;\n\tSat, 9 Sep 2017 03:59:16 +1000 (AEST)","(qmail 5763 invoked by alias); 8 Sep 2017 17:59:11 -0000","(qmail 5748 invoked by uid 89); 8 Sep 2017 17:59:11 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; q=dns; s=default; b=n88FH\n\tLgHYfFCfyg/O/N7ae/NGP2E4VRAf1gCoztXqOG3Y/rT5iXMCQ8lxGUcLoHhCtp8m\n\tKuP5aHb4zsgXBRtJ7z4qfYlioVbGR7qpBGRdOaYxyk94S2vKShPOsInij6vxjlw+\n\tIEzy1u5MRy7kj2VvrvcHQre9fhiE0UkzD1Nakw=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; s=default; bh=JrhKpR0UWsE\n\t53d4z6AcCKXYk0pY=; b=uu3JwgS6yDhPYcLi0hay6Wwh+sDK63kjcfSFVShIaK8\n\tDQ8L4kx0nDumDcbZiz4aHpZeuuWK01C7hn0JS//XMnfTwg69ygjYUKQ0+xn3PqpI\n\tDdVo9P4rO2fA8CjKG2V5GsQOdtKfNlBrmPbzlD4EjmnLwYojivIEdVpUXPMqyB7c\n\t=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.0 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=","X-HELO":"relay1.mentorg.com","Date":"Fri, 8 Sep 2017 17:59:00 +0000","From":"Joseph Myers ","To":"Albert ARIBAUD ","CC":"Zack Weinberg ,\n\tGNU C Library ","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","In-Reply-To":"<20170908194154.49d5c670.albert.aribaud@3adev.fr>","Message-ID":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t\n\t<20170908194154.49d5c670.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\n\tsvr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)"}},{"id":1765564,"web_url":"http://patchwork.ozlabs.org/comment/1765564/","msgid":"<20170908201619.465012b5.albert.aribaud@3adev.fr>","list_archive_url":null,"date":"2017-09-08T18:16:19","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":65557,"url":"http://patchwork.ozlabs.org/api/people/65557/","name":"Albert ARIBAUD (3ADEV)","email":"albert.aribaud@3adev.fr"},"content":"On Fri, 8 Sep 2017 17:59:00 +0000, Joseph Myers\n wrote :\n\n> On Fri, 8 Sep 2017, Albert ARIBAUD wrote:\n> \n> > Regarding whether the patches should land only once the kernel is\n> > Y0238-safe: these patches are intended to run even on a current and thus\n> > completely Y2038-unsafe kernel, in which case they use 64-bit-time on\n> > user side (to make applications compiled with _TIME_BITS==64 happy at\n> > least until Y2038 happens) and 32-bit time on kernel side. So I don't\n> > see why these patches should wait for a Y2038-safe kernel per se. \n> \n> Where the kernel layouts of structures are suitable for use by glibc, we'd \n> like to avoid translation layers. E.g., we need to know what the kernel's \n> struct stat64 variant for 64-bit time_t will look like to ensure no \n> translation layer is needed. (If the answer is that statx is the \n> interface that should be used for 64-bit times in struct stat so the \n> kernel doesn't need to define such a stat64 variant, then the translation \n> layer is needed anyway and we should maybe use the asm-generic 64-bit \n> struct stat variant of the layout on all 32-bit platforms.)\n\nUnderstood -- but as soon as 64-bit-time types are frozen on the kernel\nside, we could freeze the corresponding GLIBC API types (hopefully\nwithout a translation layer needed) and then if GLIBC gets out there\nbefore the kernel does, it won't be a problem since in any case the\n64-bit-time implementation must fall back to 32-bit syscalls if the\n64-bit syscalls return an ENOSYS.\n\nCordialement,\nAlbert ARIBAUD\n3ADEV","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84400-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"WxT1eBV1\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xplrf5LWmz9s7C\n\tfor ;\n\tSat, 9 Sep 2017 04:16:34 +1000 (AEST)","(qmail 84679 invoked by alias); 8 Sep 2017 18:16:29 -0000","(qmail 84670 invoked by uid 89); 8 Sep 2017 18:16:29 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\tq=dns; s=default; b=PZQNRUpCn3oawjaZ+pduTv6Orw4HRue0LXhJx46PB0U\n\t/APQrN5I9La+jeKb8syPNpA+8LffQjfa3dDVwHc5YHbmBkH014IJzQPXo3eWqIGN\n\t3Nnrwwu+Mzs+n9gZmeURBess1XuBjFZZ85DVx1qkECBVJFh6BCy7+HpAdzfFNaIQ\n\t=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\ts=default; bh=2VQB6XYJgYLca63TKJTJNs+lA3k=; b=WxT1eBV1kEfuptVBs\n\tcOhb176laeCz0FtjyfrZ3ZjvGJTlOCP8PhXoBwVowCCJehd0N8LvLq8lLul9wJH9\n\tEiN10qbJZ4A0b8qPAoMtZ0B634xE5zL0cKDItd+xdBdBKb37Rj+jPmV5/GU6LZrb\n\tl0dqAu+W/YjOuTFLyd56lEMuNM=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.6 required=5.0 tests=BAYES_00,\n\tKAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW,\n\tURIBL_RED autolearn=no version=3.3.2 spammy=Hx-languages-length:1602","X-HELO":"smtp6-g21.free.fr","Date":"Fri, 8 Sep 2017 20:16:19 +0200","From":"Albert ARIBAUD ","To":"Joseph Myers ","Cc":"Zack Weinberg , GNU C Library\n\t","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","Message-ID":"<20170908201619.465012b5.albert.aribaud@3adev.fr>","In-Reply-To":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t\n\t<20170908194154.49d5c670.albert.aribaud@3adev.fr>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit"}},{"id":1765570,"web_url":"http://patchwork.ozlabs.org/comment/1765570/","msgid":"","list_archive_url":null,"date":"2017-09-08T18:32:43","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":65878,"url":"http://patchwork.ozlabs.org/api/people/65878/","name":"Zack Weinberg","email":"zackw@panix.com"},"content":"On Fri, Sep 8, 2017 at 1:24 PM, Joseph Myers wrote:\n> On Fri, 8 Sep 2017, Zack Weinberg wrote:\n>\n>> Neither you, nor Rich, nor anyone else on the cited Austin Group\n>> discussion has addressed the actual issue, which is that this is a\n>> datum embedded in structures passed across the kernel/user boundary by\n>> reference, it is impossible to enumerate all such structures,\n>> therefore its type _must_ be a typedef so that it can be made to match\n>> the kernel's expectations, whatever those might be.\n>\n> I don't see this as in any way an issue for having a definition of struct\n> timespec that conforms to ISO C and POSIX requirements. Code passing data\n> to the kernel knows the structures being used locally and needs to convert\n> it to the kernel's layout, which might be e.g. struct __kernel_timespec64.\n\nThis only works if all such structures can be enumerated and forced\nthrough a compatibility layer. History indicates that it is not, in\nfact, possible to enumerate all such structures (the problem case I\nknow about is device-specific ioctl operations, which tend to be\ncreated by driver authors who don't realize the need for ABI\ncompatibility shims until it's too late).\n\n>> (And I don't particularly see why people seem to think this is an\n>> x32-specific issue. It potentially affects *any* 32-bit ABI on a\n>> 64-bit kernel.)\n>\n> The kernel does the conversion just fine for a pure 32-bit struct timespec\n> - as it does for the entire compat interface\n\nFor the reason given above, I confidently predict that there is at\nleast one failure to do this conversion correctly in every released\nkernel ever.\n\n>> doesn't exist in ISO C as far as I know, so how could it\n>> be? But any program that uses it opts into POSIX's specification for\n>\n> My point is that you can't expose nsec_t, even as a typedef for long, in\n> for C11.\n\nI suppose it could be __nsec_t in time.h, but I would prefer to\ninclude \"and time.h defines nsec_t\" in the scope of the willful\nviolation of C11.\n\nzw","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84401-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"DPwZHSQp\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpmCW3k5bz9sBZ\n\tfor ;\n\tSat, 9 Sep 2017 04:32:55 +1000 (AEST)","(qmail 3049 invoked by alias); 8 Sep 2017 18:32:49 -0000","(qmail 2050 invoked by uid 89); 8 Sep 2017 18:32:48 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; q=dns; s=default; b=WExC\n\t0niyqwF5SMis/yE45LJXwBQeFWHkJTMSzDsmaMyYan/1VaVHKBrDCTXFZamKB2wu\n\tmC150pqeElt0JPzZWUOL1hVvvdDFTi+3zPU5ZORIgh7uwsAkH2bs0oAqWw0HmZww\n\tBDK29JhN8U+k8GiwdPDHkEfpL2Eg0tRdpLY29z0=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; s=default; bh=RYtvpC365L\n\tZFfTQUnkEmVeFDmgU=; b=DPwZHSQpBejOklzlAVGuvj9Gakf5Fou1+uW8YOgJM9\n\tIhWILjl2BYrbZmNWUY8uykrhYQOtVU2lGC5VGDOCg2Vxyo5oV0XYmKsoXDvPl7Oi\n\tjyLRJyHwrCwZ6i3MS9fEva5vvfb1/W7as38noarArJdNYl8GtXhCIJJT2dcjBU/2\n\to=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.4 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_SORBS_SPAM, RP_MATCHES_RCVD, SPF_PASS,\n\tURIBL_RED autolearn=no version=3.3.2 spammy=","X-HELO":"mailbackend.panix.com","X-Gm-Message-State":"AHPjjUgw/98pFLLGBABfornxWrnsIx7BcQdbKyCg1aVV4JjySj0w8SWL\n\t0h5mNlZ9tIrd0Zui/u3K85znV1EmPw==","X-Google-Smtp-Source":"AOwi7QDILyTqGCyRO3D/6mo9ygLyE3Gya40Grnp2pn6rsjyJwVKOl7IuLd+5yE/6PHyEtJvbljsuKH/aPtQ84GSYjAA=","X-Received":"by 10.202.235.80 with SMTP id j77mr3947865oih.220.1504895564071; \n\tFri, 08 Sep 2017 11:32:44 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t\n\t\n\t\n\t","From":"Zack Weinberg ","Date":"Fri, 8 Sep 2017 14:32:43 -0400","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","To":"Joseph Myers ","Cc":"\"Albert ARIBAUD (3ADEV)\" ,\n\tGNU C Library ","Content-Type":"text/plain; charset=\"UTF-8\""}},{"id":1765571,"web_url":"http://patchwork.ozlabs.org/comment/1765571/","msgid":"","list_archive_url":null,"date":"2017-09-08T18:36:07","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":65878,"url":"http://patchwork.ozlabs.org/api/people/65878/","name":"Zack Weinberg","email":"zackw@panix.com"},"content":"On Fri, Sep 8, 2017 at 2:16 PM, Albert ARIBAUD wrote:\n> On Fri, 8 Sep 2017 17:59:00 +0000, Joseph Myers\n> wrote :\n>\n>> On Fri, 8 Sep 2017, Albert ARIBAUD wrote:\n>>\n>> > Regarding whether the patches should land only once the kernel is\n>> > Y0238-safe: these patches are intended to run even on a current and thus\n>> > completely Y2038-unsafe kernel, in which case they use 64-bit-time on\n>> > user side (to make applications compiled with _TIME_BITS==64 happy at\n>> > least until Y2038 happens) and 32-bit time on kernel side. So I don't\n>> > see why these patches should wait for a Y2038-safe kernel per se.\n>>\n>> Where the kernel layouts of structures are suitable for use by glibc, we'd\n>> like to avoid translation layers. E.g., we need to know what the kernel's\n>> struct stat64 variant for 64-bit time_t will look like to ensure no\n>> translation layer is needed. (If the answer is that statx is the\n>> interface that should be used for 64-bit times in struct stat so the\n>> kernel doesn't need to define such a stat64 variant, then the translation\n>> layer is needed anyway and we should maybe use the asm-generic 64-bit\n>> struct stat variant of the layout on all 32-bit platforms.)\n>\n> Understood -- but as soon as 64-bit-time types are frozen on the kernel\n> side, we could freeze the corresponding GLIBC API types (hopefully\n> without a translation layer needed) and then if GLIBC gets out there\n> before the kernel does, it won't be a problem since in any case the\n> 64-bit-time implementation must fall back to 32-bit syscalls if the\n> 64-bit syscalls return an ENOSYS.\n\nI think that's right. Syscalls we can add support for later, types\nare much more troublesome.\n\nzw","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84402-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"ScxI6jxY\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpmHQ6tDGz9sBZ\n\tfor ;\n\tSat, 9 Sep 2017 04:36:18 +1000 (AEST)","(qmail 93697 invoked by alias); 8 Sep 2017 18:36:12 -0000","(qmail 93675 invoked by uid 89); 8 Sep 2017 18:36:12 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; q=dns; s=default; b=LvmJ\n\t8S61An6mB4jUf6XafVN70MbVHHEF6dRmrFRZqZSAuGcJ87i6fod/4vRcol8fnIwy\n\tM+n9w56YHYqbuDaGNxeRQUSY0h4taTZidS3zw+/3NDVfuC0zxUFxxNt40OPPw5Pz\n\tJlLMp3WchcgTbTHgWwFP3lwDF0lO/0OPAGY9RA8=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-type; s=default; bh=1iWwedvvGQ\n\tvxwAfEnS70vQxZ1l0=; b=ScxI6jxY3iyRNaxJNv/uk9rHvfLugt1N1Vj04fZwTh\n\tLmytcV3Vd+TyQoelztYJvBQmaNCfsWnFCI+NnjxCEji3VPuk3pSpZtYWjTWAeR+t\n\tdchb+3Bf71MRlyGE6acbpei3uxlgs5WgXNEqgeLfadN+inUm41/uDIJHVBd5u86R\n\to=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.4 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_SORBS_SPAM, RP_MATCHES_RCVD, SPF_PASS,\n\tURIBL_RED autolearn=no version=3.3.2 spammy=","X-HELO":"mailbackend.panix.com","X-Gm-Message-State":"AHPjjUg1CfHEV/1Lkc2B7BzjBmkm4j2feFspGP/9vrccyKi6kusRCK/9\n\tBiHmF2fKpNwyMcMO8ZmWxFzDH5Ea2w==","X-Google-Smtp-Source":"AOwi7QDr8opRcfWeUkzHSpv6zH2ILp8M3mYxXx2z6uwJ1pPmkPGvvylhjPjqAGJ1irORK4k+L6L2mebc052G2UVSXZI=","X-Received":"by 10.202.237.149 with SMTP id l143mr3531017oih.75.1504895768389;\n\tFri, 08 Sep 2017 11:36:08 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170908201619.465012b5.albert.aribaud@3adev.fr>","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t\n\t<20170908194154.49d5c670.albert.aribaud@3adev.fr>\n\t\n\t<20170908201619.465012b5.albert.aribaud@3adev.fr>","From":"Zack Weinberg ","Date":"Fri, 8 Sep 2017 14:36:07 -0400","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","To":"Albert ARIBAUD ","Cc":"Joseph Myers ,\n\tGNU C Library ","Content-Type":"text/plain; charset=\"UTF-8\""}},{"id":1765593,"web_url":"http://patchwork.ozlabs.org/comment/1765593/","msgid":"<20170908211927.4f46a7f7.albert.aribaud@3adev.fr>","list_archive_url":null,"date":"2017-09-08T19:19:27","subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","submitter":{"id":65557,"url":"http://patchwork.ozlabs.org/api/people/65557/","name":"Albert ARIBAUD (3ADEV)","email":"albert.aribaud@3adev.fr"},"content":"Hi Joseph,\n\nOn Fri, 8 Sep 2017 17:26:26 +0000, Joseph Myers\n wrote :\n\n> On Fri, 8 Sep 2017, Albert ARIBAUD wrote:\n> \n> > > * Documentation of _TIME_BITS is clearly needed. \n> > \n> > Where should this documentation go? \n> \n> In manual/creature.texi, alongside the documentation of _FILE_OFFSET_BITS.\n\nThanks, will do in 01/52 of v2.\n\n> (It occurred to me that patches 50-52 don't seem to have reached the \n> mailing list, so I don't know what was in them.)\n\nYou're correct. I did not get any NDR so I cannot tell what happened...\nI have sent the rest (threaded properly after 49/52, although missing\n\"References:\" headers to 0/48 and previous).\n\nCordialement,\nAlbert ARIBAUD\n3ADEV","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84403-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"BNvI5OJy\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpnFT5y0Cz9sRV\n\tfor ;\n\tSat, 9 Sep 2017 05:19:41 +1000 (AEST)","(qmail 25585 invoked by alias); 8 Sep 2017 19:19:35 -0000","(qmail 25572 invoked by uid 89); 8 Sep 2017 19:19:35 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\tq=dns; s=default; b=Sz8GpGzmGSFYNQj3jwwe+bRQlsIJ+01+hxovyfFGcA2\n\tkLu1G+fq+0KmhHwvKHrtm+TawIIAGHyfrpGY2/RkqlFaQR+JvVF1uU3lFOJz1B7O\n\tWfaA5clxk/Ubq1Y8Iny6eRWFWugPQ5EJeZzzxmQCpczhp1mFUGtC2XMtVSa+CB+M\n\t=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\ts=default; bh=gxdyCATNnXCuwiEd62BCHlJ5wEs=; b=BNvI5OJytXSyDa9Zj\n\tVyTzBaVX9OQ6UIsZNMn3RgFNxKzgi1ZJVZWaO3PnddUOSPaQXOJ6lH3UL+HkPpfR\n\tv7zt/ctRN0qI5swMWsYmGGpxUgKYHNmKfwnBj+ccyZ7JuPmw+fw7qQ5fnw5DTbHb\n\tZo43qoyAbUgBD2a8sio+O0PF2Y=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.6 required=5.0 tests=BAYES_00,\n\tKAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW,\n\tURIBL_RED autolearn=no version=3.3.2 spammy=","X-HELO":"smtp6-g21.free.fr","Date":"Fri, 8 Sep 2017 21:19:27 +0200","From":"Albert ARIBAUD ","To":"Joseph Myers ","Cc":"","Subject":"Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof","Message-ID":"<20170908211927.4f46a7f7.albert.aribaud@3adev.fr>","In-Reply-To":"","References":"<20170907224219.12483-1-albert.aribaud@3adev.fr>\n\t\n\t<20170908190832.03476c79.albert.aribaud@3adev.fr>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit"}}]