Potential issues with the snippet to parse SOURCE_DATE_EPOCH in C

[Bernhard M. Wiedemann]

On 19/01/2024 21.03, Chris Lamb wrote:
>> Was there any reason to reject >ULONG_MAX? I'm touching this code,
>> and don't see a reason for it; it looks very arbitrary; especially
>> since some systems can have 32-bit long, but 64-bit time_t. Should I
>> just drop that check, or keep it? And why?

There is another issue with the ULONG_MAX - that is it allows to 
represent timestamps up to 2106, but a 32-bit time_t is a signed int32, 
so will roll over in 2038 back to 1901.

At some (not too far) point in time, programs and libraries compiling 
with glibc should start to build with -D_TIME_BITS=64 
-D_FILE_OFFSET_BITS=64 to get 64-bit time_t everywhere. [1]

Ciao
Bernhard M.

[1] 
https://www.reddit.com/r/linux/comments/19a95cl/today_is_y2k38_commemoration_day_t14/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20240122/a7c30f19/attachment.sig>