Length of User names

[der Mouse]

In article <16322 at smoke.brl.mil>, gwyn at smoke.brl.mil (Doug Gwyn) writes:
> In article <1991Jun1.194721.25383 at thunder.mcrcim.mcgill.edu> mouse at thunder.mcrcim.mcgill.edu (der Mouse) writes:
>> Fortunately, it's not hard to do.  I once asked someone at Waterloo,
>> which uses usernames >8 chars on their UNIX machines, how they did
>> it, and was informed that you just need to change a couple of
>> include files (<utmp.h> comes to mind) and recompile everything.
> For an example of why hacking the system interface is harmful,
> consider those applications that attempt to get usernames and provide
> only 8+1 characters of storage for them, because that was a known
> feature of the operating system implementation.

Such programs are broken as written.  From <utmp.h>, SunOS 4.1:

	/*	@(#)utmp.h 1.8 88/08/19 SMI; from UCB 4.2 83/05/22	*/
[...]
	/*
	 * Structure of utmp and wtmp files.
	 *
	 * XXX - Assuming the number 8 is unwise.
	 */
	struct utmp {
		char	ut_line[8];		/* tty name */
		char	ut_name[8];		/* user id */
		char	ut_host[16];		/* host name, if remote */
		long	ut_time;		/* time on */
	};

(Presumably assuming the number 16 is OK :-)  

Our mtXinu 4.3+NFS system is the same, except it is missing the XXX.
Its ID string is
	 *	@(#)utmp.h	5.1 (Berkeley) 5/30/85

> Longer user names will break such programs, and no it is NOT
> practical to find them all and change them.

Changing int to 32 bits will break programs that assume int is 16 bits
- and there are lots of them, and it is NOT practical to find them all
and change them.  ...uh, oh yeah, that was a few years ago.  Funny, but
it seems to have happened anyway.  (I take a rather hard line towards
programs that depend on not-promised things, particularly in the face
of explicit warnings against doing so, and most especially when a
trivial better way (sizeof in this case) is available.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu