On Sat, 27 Jul 2024 00:35:33 +0200 Bernhard Übelacker wrote: [...] > Hello,
Hi there! Thanks for following up on my bug report. :-) > I just tried to debug the issue and found this is caused by the line below. > > src/wtmpdb.c: > 365 uint64_t login_t = strtoul(argv[3], &endptr, 10); > 366 if ((errno == ERANGE && login_t == UINT64_MAX) > > Unfortuantely returns the strtoul an overflow error which gets > through unnoticed because strtoul returns ULONG_MAX instead of UINT64_MAX. Good, so there is something to be fixed in the program, as I suspected. > > And found this issue got reported already upstream > and it got fixed a few hours ago using strtoull by this commit (and new > release v0.13.0): > > > https://github.com/thkukuk/wtmpdb/commit/f3ca146227ecca42ec1562d60fa4856fbc0ca4af I am happy there's a fix (although I admit that I do not fully understand it...). Thanks for informing me, looking forward to seeing the fixed version packaged and uploaded to Debian unstable. P.S.: If anyone is curious about what I do not fully understand, here's my naive reasoning: the strtoull(3) man page states that strtoull returns an 'unsigned long long' (which is guaranteed to be at least 64 bit wide, but could be wider than 64 bit on some architectures, in principle...); but the returned value is assigned to a variable of type 'uint64_t' (which is always exactly 64 bit wide); what happens on an (existing or hypothetical) architecture where the width of 'unsigned long long' is greater than 64 bit? is the returned value converted from 'unsigned long long' to 'uint64_t'? if this is the case, how can login_t ever be equal to ULLONG_MAX, on architectures where ULLONG_MAX is strictly greater than UINT64_MAX ? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpcuKPHO2Vkc.pgp
Description: PGP signature
