From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63964 invoked by alias); 25 Sep 2018 19:44:34 -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 63952 invoked by uid 89); 25 Sep 2018 19:44:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=cordialement, 3adev, H*r:212.27.42, 3ADEV X-HELO: smtp3-g21.free.fr Date: Tue, 25 Sep 2018 19:44:00 -0000 From: Albert ARIBAUD To: Joseph Myers Cc: Subject: Re: [PATCH] Y2038: add struct __timespec64 Message-ID: <20180925214425.390377a9@athena> In-Reply-To: References: <20180919072701.27535-1-albert.aribaud@3adev.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00450.txt.bz2 Hi Joseph, On Wed, 19 Sep 2018 15:00:33 +0000, Joseph Myers wrote : > On Wed, 19 Sep 2018, Joseph Myers wrote: > > > The bit-fields needs to be *anonymous* for initializers to work as > > intended. It can't have the name tv_pad that it has in this patch, or any > > other name, with our without leading underscores. > > Ignore this, I see you are distinguishing between an internal type here > with a named field and a public type with an anonymous field. Indeed I am, and rather than ignoring your remark, I'll take it as a sign that my comment is possibly confusing and needs to make it explicit that there are two types, one private to glibc and one public. > *But* I wouldn't expect the internal type to be declared in any public > header at all. That is, this should not be a bits/ header at all, not an > installed header, because it would only be used in implementation code, > not from any public interface. So you need to rename the header out of > the bits/ namespace, which is purely for installed headers, and remove all > the #includes from installed headers. Ok. > Regarding the comment you have on this type: 2038, not 2036; things, not > tings; don't reference timeval at all (describing timespec in terms of > timeval is a very historical way of writing a comment, that may have made > sense when timeval was the established type and timespec was the new one, > but doesn't make sense for over 20 years now; rather, comments on timeval > should describe it as a legacy type, superseded by timespec). Will fix. Cordialement, Albert ARIBAUD 3ADEV