From naddy@mips.inka.de  Sat Dec 21 21:03:54 2013
Return-Path: <naddy@mips.inka.de>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hub.freebsd.org (Postfix) with ESMTPS id 3F75BBC3
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 21 Dec 2013 21:03:54 +0000 (UTC)
Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46])
	(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.freebsd.org (Postfix) with ESMTPS id E65F4124B
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 21 Dec 2013 21:03:53 +0000 (UTC)
Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15])
	by mx.arcor.de (Postfix) with ESMTP id 2B38B10C6A2
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 21 Dec 2013 22:03:45 +0100 (CET)
Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47])
	by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 24C5E1F600A
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 21 Dec 2013 22:03:45 +0100 (CET)
Received: from lorvorc.mips.inka.de (dslb-094-218-178-083.pools.arcor-ip.net [94.218.178.83])
	by mail-in-07.arcor-online.net (Postfix) with ESMTPS id E0AF4107A6B
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 21 Dec 2013 22:03:44 +0100 (CET)
Received: from lorvorc.mips.inka.de (localhost [127.0.0.1])
	by lorvorc.mips.inka.de (8.14.7/8.14.7) with ESMTP id rBLL3inJ038993
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 21 Dec 2013 22:03:44 +0100 (CET)
	(envelope-from naddy@lorvorc.mips.inka.de)
Received: (from naddy@localhost)
	by lorvorc.mips.inka.de (8.14.7/8.14.7/Submit) id rBLL3ihA038992;
	Sat, 21 Dec 2013 22:03:44 +0100 (CET)
	(envelope-from naddy)
Message-Id: <201312212103.rBLL3ihA038992@lorvorc.mips.inka.de>
Date: Sat, 21 Dec 2013 22:03:44 +0100 (CET)
From: Christian Weisgerber <naddy@FreeBSD.org>
Reply-To: Christian Weisgerber <naddy@FreeBSD.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Sync L_cuserid with MAXLOGNAME
X-Send-Pr-Version: 3.114
X-GNATS-Notify:

>Number:         185077
>Category:       kern
>Synopsis:       [headers] [patch] Sync L_cuserid with MAXLOGNAME
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Dec 21 21:10:01 UTC 2013
>Closed-Date:    
>Last-Modified:  Sun Apr 20 21:55:07 UTC 2014
>Originator:     Christian Weisgerber
>Release:        FreeBSD 9.2-STABLE amd64
>Organization:
>Environment:

Affects HEAD and FreeBSD 10.
	
>Description:

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.

>How-To-Repeat:

>Fix:

Index: stdio.h
===================================================================
--- stdio.h	(revision 259696)
+++ stdio.h	(working copy)
@@ -291,7 +291,7 @@
  * Functions defined in all versions of POSIX 1003.1.
  */
 #if __BSD_VISIBLE || __POSIX_VISIBLE <= 199506
-#define	L_cuserid	17	/* size for cuserid(3); MAXLOGNAME, legacy */
+#define	L_cuserid	33	/* size for cuserid(3); MAXLOGNAME, legacy */
 #endif
 
 #if __POSIX_VISIBLE
>Release-Note:
>Audit-Trail:

From: Jilles Tjoelker <jilles@stack.nl>
To: bug-followup@FreeBSD.org, naddy@FreeBSD.org
Cc:  
Subject: Re: kern/185077: Sync L_cuserid with MAXLOGNAME
Date: Sun, 22 Dec 2013 22:50:44 +0100

 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

From: Christian Weisgerber <naddy@mips.inka.de>
To: Jilles Tjoelker <jilles@stack.nl>
Cc: bug-followup@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@mips.inka.de
>Unformatted:
