Re: [RFC] y2038: test: Add _Static_assert() check when __USE_TIME_BITS64 is defined

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]