Bug 185077 - [headers] [patch] Sync L_cuserid with MAXLOGNAME
Summary: [headers] [patch] Sync L_cuserid with MAXLOGNAME
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.2-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-21 21:10 UTC by Christian Weisgerber
Modified: 2017-12-31 22:23 UTC (History)
0 users

See Also:


Attachments
file.diff (434 bytes, patch)
2013-12-21 21:10 UTC, Christian Weisgerber
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Weisgerber freebsd_committer 2013-12-21 21:10:01 UTC
L_cuserid must match MAXLOGNAME.  When MAXLOGNAME was bumped to 33
in <sys/param.h>, L_cuserid in <stdio.h> was forgotten.

Fix: Bump L_cuserid to 33.

Alternatively, for HEAD, consider completely removing cuserid(3)
from libcompat and L_cuserid with it.
Comment 1 Jilles Tjoelker freebsd_committer 2013-12-22 21:50:44 UTC
In PR kern/185077, you wrote:
> L_cuserid must match MAXLOGNAME. When MAXLOGNAME was bumped to 33 in
> <sys/param.h>, L_cuserid in <stdio.h> was forgotten.

> Fix: Bump L_cuserid to 33.

Since cuserid() is only in libcompat which is only a static library,
making this change does not break ABI.

I still wonder whether it's worth it, though. What breaks if L_cuserid
!= MAXLOGNAME? They are different constants, so may have different
values.

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.

> 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.

Parts of me, however, like the ability of compiling ancient source code,
be it with -lcompat and other strange options.

-- 
Jilles Tjoelker
Comment 2 Christian Weisgerber 2013-12-22 22:58:53 UTC
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@mips.inka.de
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:13 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped