From: Paul Eggert <eggert@cs.ucla.edu>
To: Lukasz Majewski <lukma@denx.de>,
Joseph Myers <joseph@codesourcery.com>,
Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Alistair Francis <alistair23@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
Alistair Francis <alistair.francis@wdc.com>,
GNU C Library <libc-alpha@sourceware.org>,
Florian Weimer <fweimer@redhat.com>,
Carlos O'Donell <carlos@redhat.com>,
Stepan Golosunov <stepan@golosunov.pp.ru>,
Andreas Schwab <schwab@suse.de>, Zack Weinberg <zackw@panix.com>,
Siddhesh Poyarekar <siddhesh@redhat.com>
Subject: Re: [RFC] y2038: test: Add _Static_assert() check when __USE_TIME_BITS64 is defined
Date: Wed, 9 Dec 2020 16:42:44 -0800 [thread overview]
Message-ID: <2558832c-adac-0670-f39b-417ffa10f8a6@cs.ucla.edu> (raw)
In-Reply-To: <20201209145331.18819-1-lukma@denx.de>
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.
next prev parent reply other threads:[~2020-12-10 0:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 14:53 Lukasz Majewski
2020-12-10 0:42 ` Paul Eggert [this message]
2020-12-13 11:48 ` Lukasz Majewski
2020-12-15 18:54 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2558832c-adac-0670-f39b-417ffa10f8a6@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=adhemerval.zanella@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=arnd@arndb.de \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=lukma@denx.de \
--cc=schwab@suse.de \
--cc=siddhesh@redhat.com \
--cc=stepan@golosunov.pp.ru \
--cc=zackw@panix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).