kern/185077: Sync L_cuserid with MAXLOGNAME
Christian Weisgerber
naddy at mips.inka.de
Sun Dec 22 23:40:01 UTC 2013
The following reply was made to PR kern/185077; it has been noted by GNATS.
From: Christian Weisgerber <naddy at mips.inka.de>
To: Jilles Tjoelker <jilles at stack.nl>
Cc: bug-followup at FreeBSD.org
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 naddy at mips.inka.de
More information about the freebsd-bugs
mailing list