https://bugs.openldap.org/show_bug.cgi?id=8890

--- Comment #16 from Ryan Tandy ryan@openldap.org --- Debian and Ubuntu have both switched their remaining 32-bit architectures, except for i686, to 64-bit time_t. The change is in Ubuntu 24.04 (already released) and Debian 13/trixie (not yet released).

Steve Langasek committed this distro patch:

https://salsa.debian.org/openldap-team/openldap/-/blob/2a8f9240b9b6fd577d913...

It's mostly the same as what was previously proposed in this ITS (changing %ld format specifiers to %lld), and unfortunately contains the same smbk5pwd bug that was already commented on.

I didn't understand Howard's comment ('the unconditional use of "long long" instead of "long" will break on machines where "long long" is not 64 bits'). My understanding is C specifies "long long" to be at least 64 bits, and I'm not aware of any existing systems (yet) where "long long" is 128 bits - is it more of a futureproofing concern? Casting to long long and formatting with %lld seems to be the generally accepted solution in the broader community. If that's not acceptable, maybe scripting configure to generate a PRI_TIME_T format specifier?

Steve's patch comment mentions an assertion failure in test046-dds on 32-bit ARM:

servers/slapd/overlays/dds.c:422: dds_op_add: Assertion `bv.bv_len < sizeof( ttlbuf )' failed.

I have not reproduced it myself (I don't have ARM hardware, and it isn't happening for me on x86). I note that the assertion ttl <= DDS_RF2589_MAX_TTL just above did not fail; but that does not rule out corruption of either the 64-bit value (could be negative) or the 32-bit quantity read by snprintf. I haven't figured out what actually happened here, but it's irritating me.