One more report, sorry... As the title says. If you put "1234" in the ut_field of the utmpx, call pututxline() and then read it back, you get "123" back. An od(1) dump of the utmp file shows that what is stored is 1, 2, 3 and \0.
This is a problem for example with ssh (OpenSSH to be precise, I don't know what Dropbear does) and pseudo-terminals. OpenSSH uses the last 4 characters of the pty as the id field. So for example if one user is connected to /dev/pts/0, the id used for utmp is "ts/0". If another user is connected to /dev/pts/1, the id is "ts/1". And so forth. With the truncation glitch both entries are recorded with id "ts/". Which should become an issue when it comes to searching for the right record when one of the users logs out and utmp is updated, since they both collide. And yet for some unfathomable reason the correct record gets found and updated as per my limited testing. I looked briefly at the code, client and server-side, but didn't see anything obvious. There must be a simple off-by-1 calculation or indexing error somewhere. Thanks.