From owner-svn-src-all@FreeBSD.ORG Mon Aug 24 11:16:45 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF31106568E; Mon, 24 Aug 2009 11:16:45 +0000 (UTC) (envelope-from ed@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 118A08FC08; Mon, 24 Aug 2009 11:16:45 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id n7OBGiGw093254; Mon, 24 Aug 2009 11:16:44 GMT (envelope-from ed@svn.freebsd.org) Received: (from ed@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id n7OBGi2j093252; Mon, 24 Aug 2009 11:16:44 GMT (envelope-from ed@svn.freebsd.org) Message-Id: <200908241116.n7OBGi2j093252@svn.freebsd.org> From: Ed Schouten Date: Mon, 24 Aug 2009 11:16:44 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r196508 - head/lib/libc/stdlib X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 11:16:45 -0000 Author: ed Date: Mon Aug 24 11:16:44 2009 New Revision: 196508 URL: http://svn.freebsd.org/changeset/base/196508 Log: Our implementation of granpt(3) could be valid in the future. When I wrote the pseudo-terminal driver for the MPSAFE TTY code, Robert Watson and I agreed the best way to implement this, would be to let posix_openpt() create a pseudo-terminal with proper permissions in place and let grantpt() and unlockpt() be no-ops. This isn't valid behaviour when looking at the spec. Because I thought it was an elegant solution, I filed a bug report at the Austin Group about this. In their last teleconference, they agreed on this subject. This means that future revisions of POSIX may allow grantpt() and unlockpt() to be no-ops if an open() on /dev/ptmx (if the implementation has such a device) and posix_openpt() already do the right thing. I'd rather put this in the manpage, because simply mentioning we don't comply to any standard makes it look worse than it is. Right now we don't, but at least we took care of it. Approved by: re (kib) MFC after: 3 days Modified: head/lib/libc/stdlib/ptsname.3 Modified: head/lib/libc/stdlib/ptsname.3 ============================================================================== --- head/lib/libc/stdlib/ptsname.3 Mon Aug 24 11:13:32 2009 (r196507) +++ head/lib/libc/stdlib/ptsname.3 Mon Aug 24 11:16:44 2009 (r196508) @@ -134,14 +134,22 @@ The slave pseudo-terminal device could n The .Fn ptsname function conforms to -.St -p1003.1-2001 . +.St -p1003.1-2008 . .Pp This implementation of .Fn grantpt and .Fn unlockpt -does not comply with any standard, because these functions assume the -pseudo-terminal has the correct attributes upon creation. +does not conform to +.St -p1003.1-2008 , +because it depends on +.Xr posix_openpt 2 +to create the pseudo-terminal device with proper permissions in place. +It only validates whether +.Fa fildes +is a valid pseudo-terminal master device. +Future revisions of the specification will likely allow this behaviour, +as stated by the Austin Group. .Sh HISTORY The .Fn grantpt , @@ -150,15 +158,3 @@ and .Fn unlockpt functions appeared in .Fx 5.0 . -.Sh NOTES -The purpose of the -.Fn grantpt -and -.Fn unlockpt -functions has no meaning in -.Fx , -because pseudo-terminals obtained by -.Xr posix_openpt 2 -are created on demand. -Because these devices are created with proper permissions in place, they -are guaranteed to be unused by unprivileged processes.