Bug 185077

Comment 1 Jilles Tjoelker 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

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

Comment 4 Graham Perrin 2022-10-17 12:36:47 UTC

Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>

Comment 5 Mark Linimon 2023-10-22 15:07:05 UTC

^Triage: assign to bugmeister.

To submitter: is this antique PR still relevant?

Comment 6 Christian Weisgerber 2023-10-22 15:42:43 UTC

(In reply to Mark Linimon from comment #5)
Well, all the technical discussion above still applies.

Comment 7 Mark Linimon 2023-12-26 00:02:21 UTC

^Triage: release from bugmeister queue after feedback.