Re: kern/185077: Sync L_cuserid with MAXLOGNAME

The following reply was made to PR kern/185077; it has been noted by GNATS.

From: Christian Weisgerber <[e-mail]>
To: Jilles Tjoelker <[e-mail]>
Cc: [e-mail]
Subject: Re: kern/185077: Sync L_cuserid with MAXLOGNAME
Date: Sun, 22 Dec 2013 23:58:53 +0100

 Jilles Tjoelker:
 
 > I still wonder whether it's worth it, though. What breaks if L_cuserid
 > != MAXLOGNAME? They are different constants, so may have different
 > values.
 
 If there are sufficiently long user names on a system, cuserid(buf)
 will truncate them on return.  See lib/libcompat/4.4/cuserid.c.
 
 > This breakage should be weighed against the possible breakage resulting
 > from changing things about cuserid() and L_cuserid, since they are
 > obsolete APIs used by old crufty code.
 
 I'd say any possibility of breakage there--basically, calling
 cuserid(buf) with a buffer that has a fixed size but not based on
 L_cuserid--was already hit when L_cuserid was bumped from the
 original 9 to 17.
 
 > > Alternatively, for HEAD, consider completely removing cuserid(3) from
 > > libcompat and L_cuserid with it.
 > 
 > This is an option. It looks like cuserid() is mostly used by high-level
 > languages to make it available to high-level language code.
 
 OpenBSD recently removed all of libcompat.  The ports fallout there
 from cuserid was minimal and easily fixed: Two users of cuserid()
 (games/late, games/xpat2) and two users of L_cuserid (lang/mono,
 cad/chipmunk).
 
 > Parts of me, however, like the ability of compiling ancient source code,
 > be it with -lcompat and other strange options.
 
 gtty(), stty(), and the regexp(3) functions have already been removed
 from libcompat over the years.
 
 -- 
 Christian "naddy" Weisgerber                          [e-mail]
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[e-mail]"