[RFC] y2038: test: Add _Static_assert() check when __USE_TIME_BITS64 is defined
Lukasz Majewski
lukma@denx.de
Sun Dec 13 11:48:24 GMT 2020
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20201213/02366f0e/attachment.sig>
More information about the Libc-alpha
mailing list