https://bugs.openldap.org/show_bug.cgi?id=8890
--- Comment #17 from tg@debian.org tg@debian.org --- On Sat, 21 Sep 2024, openldap-its@openldap.org wrote:
I didn't understand Howard's comment ('the unconditional use of "long long"
[…]
Looking at it *again*, with some years of distance, I *think* I now see what Howard’s barely comprehensible and rather rude comments were meant to point out.
I did not see it at that time because ⓐ I was trying, and, as a nōn-English-native speaker, failing to puzzle out what he was saying, and ⓑ the OpenLDAP code’s use of abstractions here has massively reduced its legibility.
+ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time());
I think the first line of that is the point of critique. On repeat reading, it looks like it tries to figure out how many bytes are needed to represent a long, then allocates a buffer sized by this.
As I correctly pointed out, this is a separate issue. However, Howard rejected both the immediate fix of printing wrong data RIGHT NOW (and likely truncating that at some point in the future) and this follow-up bug to address that truncation.
AIUI, this should likely be something like:
+- keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); ++ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time());
Of course, someone who actually knows wth LDAP_PVT_INTTYPE_CHARS is needs to ensure that it DTRT for an argument of “long long” first.
bye, //mirabilos
-
openldap-its＠openldap.org