Message ID | 20201209145331.18819-1-lukma@denx.de |
---|---|
State | Superseded |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 976AE396EC90; Wed, 9 Dec 2020 14:54:23 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) by sourceware.org (Postfix) with ESMTPS id ABD2F386F439 for <libc-alpha@sourceware.org>; Wed, 9 Dec 2020 14:54:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ABD2F386F439 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=lukma@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4Crg6x0wBGz1ryWv; Wed, 9 Dec 2020 15:54:17 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4Crg6w5zjcz1tnH8; Wed, 9 Dec 2020 15:54:16 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id 6Pm_qdxHysi7; Wed, 9 Dec 2020 15:54:15 +0100 (CET) X-Auth-Info: Pqyqns5uLBv6Qi9EnGQYlAomg/LBLw2+cI5qKcS95u0= Received: from localhost.localdomain (89-64-25-12.dynamic.chello.pl [89.64.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Wed, 9 Dec 2020 15:54:15 +0100 (CET) From: Lukasz Majewski <lukma@denx.de> To: Joseph Myers <joseph@codesourcery.com>, Paul Eggert <eggert@cs.ucla.edu>, Adhemerval Zanella <adhemerval.zanella@linaro.org> Subject: [RFC] y2038: test: Add _Static_assert() check when __USE_TIME_BITS64 is defined Date: Wed, 9 Dec 2020 15:53:31 +0100 Message-Id: <20201209145331.18819-1-lukma@denx.de> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Cc: Florian Weimer <fweimer@redhat.com>, GNU C Library <libc-alpha@sourceware.org>, Siddhesh Poyarekar <siddhesh@redhat.com>, Andreas Schwab <schwab@suse.de>, Stepan Golosunov <stepan@golosunov.pp.ru>, Alistair Francis <alistair.francis@wdc.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
[RFC] y2038: test: Add _Static_assert() check when __USE_TIME_BITS64 is defined
|
|
Commit Message
Lukasz Majewski
Dec. 9, 2020, 2:53 p.m. UTC
This check is added to exported time/time.h file to check in the compile time if time_t and struct timespec have proper sizes and alignment. It shall prevent from compiling user programs with -D_TIME_BITS=64 when time related data structures are not supporting 64 bit time. --- time/time.h | 8 ++++++++ 1 file changed, 8 insertions(+)
Comments
On 12/9/20 6:53 AM, Lukasz Majewski wrote: > +#define CHECK_TIME64_SIZE(__name, __len) \ > + _Static_assert (sizeof (__name) == __len, "Size of " #__name " != " #__len) > + > +#ifdef __USE_TIME_BITS64 > + CHECK_TIME64_SIZE(time_t, 8); > + CHECK_TIME64_SIZE(struct timespec, 16); > +#endif I've lost context here; what branch is this against? glibc master doesn't have __USE_TIME_BITS64. If this is in a publicly-visible file, the macro CHECK_TIME64_SIZE would need to have a reserved name. I'm leery of the idea of putting checks like this into include files that users see. If there's a reason a platform cannot support 64-bit time_t even though __USE_TIME_BITS64 is defined, doesn't this sort of checking belong in the include file that defines time_t or __TIME_T_TYPE or whatever? That way, a user who sees the resulting diagnostic will have an easier time figuring out what exactly went wrong.
Hi Paul, Thank you for the reply. > On 12/9/20 6:53 AM, Lukasz Majewski wrote: > > > +#define CHECK_TIME64_SIZE(__name, __len) \ > > + _Static_assert (sizeof (__name) == __len, "Size of " #__name " > > != " #__len) + > > +#ifdef __USE_TIME_BITS64 > > + CHECK_TIME64_SIZE(time_t, 8); > > + CHECK_TIME64_SIZE(struct timespec, 16); > > +#endif > > I've lost context here; what branch is this against? glibc master > doesn't have __USE_TIME_BITS64. Yes, it doesn't (yet) support it. This will be available when _TIME_BITS=64 is supported on ports with __WORDSIZE=32 && __TIMESIZE!=64. > > If this is in a publicly-visible file, the macro CHECK_TIME64_SIZE > would need to have a reserved name. Ok. I see - we will stumble upon the reserved namespaces for POSIX compliant exported headers. > > I'm leery of the idea of putting checks like this into include files > that users see. The idea here is to prevent compiling user's program on machine, which will not properly support 64 bit times - for example the underlying glibc was very old. I do know that this is not preventing from all threads - as one can just copy binary from some similar system. It was suggested once (by Adhemerval and Andreas) that _Static_asserts shall be added to glibc, but I'm a bit confused: 1. If the check is added to exported headers, it will (probably) pollute the header itself (like in this patch). 2. I could add it into the glibc sources, but then I shall NOT use __USE_TIME_BITS64 for enabling it, as this is #define from exported header (and is not visible during glibc build itself). Instead, maybe I should use __WORDSIZE==32 && __TIMESIZE!=64 as the condition? > If there's a reason a platform cannot support 64-bit > time_t even though __USE_TIME_BITS64 is defined, doesn't this sort of > checking belong in the include file that defines time_t or > __TIME_T_TYPE or whatever? That way, a user who sees the resulting > diagnostic will have an easier time figuring out what exactly went > wrong. Interesting, thanks for the idea. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On 12/13/20 3:48 AM, Lukasz Majewski wrote: > Instead, maybe I > should use __WORDSIZE==32 && __TIMESIZE!=64 as the condition? Sounds reasonable. And that could be done with #if and so would generate better diagnostics for pre-C11 compilers (assuming this stuff is in an exported header).
diff --git a/time/time.h b/time/time.h index 9a74f01b2f..d293ff3dc5 100644 --- a/time/time.h +++ b/time/time.h @@ -446,4 +446,12 @@ extern int getdate_r (const char *__restrict __string, __END_DECLS +#define CHECK_TIME64_SIZE(__name, __len) \ + _Static_assert (sizeof (__name) == __len, "Size of " #__name " != " #__len) + +#ifdef __USE_TIME_BITS64 + CHECK_TIME64_SIZE(time_t, 8); + CHECK_TIME64_SIZE(struct timespec, 16); +#endif + #endif /* time.h. */