features-time64.h on non-linux 32b platforms

[Paul Eggert]

On 2026-08-25 00:01, Samuel Thibault wrote:
> Paul Eggert, le lun. 24 août 2026 23:56:14 -0700, a ecrit:
>> On 2026-08-24 23:48, Samuel Thibault wrote:
>>> Ok, but what about existing non-linux 32bit ports?
>>
>> There's just one such port, right? hurd-i386.
> 
> In-tree, yes. Out-of-tree, there may still be some foo-gnu porting
> efforts which we do not know.

In theory, yes. In practice, surely not.


>> Which app defines _TIME_BITS=64 and blindly expects that to work on hurd-i386?
> 
> gcli does.

I don't see _TIME_BITS mentioned in the gcli source code that I got from <https://gitlab.com/herrhotzenplotz/gcli.git>. Are we talking about the same gcli?

Did someone attempt to configure that gcli with './configure CFLAGS=-D_TIME_BITS=64' and complain that the build silently ignored _TIME_BITS? If that's what happened, it's more a builder problem than an app problem. Though I would kinda expect builders for hurd-i386 to know that the platform stops working in the year 2038. If that's not the case, perhaps the Hurd should be changed to warn people more loudly about the issue. E.g., when you login you get a big banner saying "THIS SYSTEM SELF-DESTRUCTS IN 359840430 SECONDS." with that number getting smaller at each login....

If it would be useful for builds like that to fail, perhaps you could add an #error check to glibc's sysdeps/mach/hurd/bits/timesize.h. That would be less intrusive than messing with sysdeps/generic etc. Yes, in theory one should make such a change generic to all 32-bit-only time_t platforms, but when there is only one such platform....