Re: [PATCH v2] time: Fix overflow itimer tests on 32-bit systems

[Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>]

On 17/08/2021 20:33, Stafford Horne via Libc-alpha wrote:
> On Tue, Aug 17, 2021, 7:33 AM Joseph Myers <joseph@codesourcery.com> wrote:
> 
>> On Tue, 17 Aug 2021, Stafford Horne via Libc-alpha wrote:
>>
>>> Should we provide __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 for not linux
>> builds,
>>> or remove __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 from the itimer test
>> again?
>>> The reason for using __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 is to pick
>> up the
>>> timeval size which is different on each architecture.
>>
>> I'd suggest having a macro that doesn't refer to either "kernel" or "old
>> timeval" (and that is defined for both Linux and Hurd).  As far as I
>> understand, the logical concept that's relevant for this test isn't either
>> one of those, it's more like "setitimer supports times that cannot be
>> represented in 32 bits".
>>
> 
> Hello,
> 
> That makes sense, currently with the hurd build being broken how urgent is
> this?  I worked on reproducing the build issue with build-many but didn't
> get it working yet, probably about 80% there before I ran out of time.
> 
> I'll try to get it fixed in a few days as my top priority, but I only have
> an hour or two a day to look at it. If we need to revert or add a temporary
> patch please feel free.

The most straightforward would be to add a libsupport routine to abstract
what Joseph has suggested:

support/xtime.h:

  bool support_setitimer_support_64_bit (void);

And return 0 for hurd and __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 for Linux.