From owner-freebsd-standards@FreeBSD.ORG Sun Mar 13 19:54:54 2011 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B6161065670 for ; Sun, 13 Mar 2011 19:54:54 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id C6D898FC14 for ; Sun, 13 Mar 2011 19:54:53 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3FEF245C9B; Sun, 13 Mar 2011 20:33:43 +0100 (CET) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id AFA6445C8A; Sun, 13 Mar 2011 20:33:28 +0100 (CET) Date: Sun, 13 Mar 2011 20:33:20 +0100 From: Pawel Jakub Dawidek To: Jilles Tjoelker Message-ID: <20110313193320.GC40734@garage.freebsd.pl> References: <20110312170123.GT78089@deviant.kiev.zoral.com.ua> <20110312193131.GA97300@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ncSAzJYg3Aa9+CRW" Content-Disposition: inline In-Reply-To: <20110312193131.GA97300@stack.nl> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-standards@freebsd.org Subject: Re: open(O_NOFOLLOW) error when encountered symlink X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 19:54:54 -0000 --ncSAzJYg3Aa9+CRW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 12, 2011 at 08:31:32PM +0100, Jilles Tjoelker wrote: > On Sat, Mar 12, 2011 at 07:01:23PM +0200, Kostik Belousov wrote: > > Hello, > > I noted the following discussion and commits in the gnu tar repository: >=20 > > http://lists.gnu.org/archive/html/bug-tar/2010-11/msg00080.html > >=20 > > http://git.savannah.gnu.org/cgit/tar.git/commit/?id=3D1584b72ff271e7f82= 6dd64d7a1c7cd2f66504acb > > http://git.savannah.gnu.org/cgit/tar.git/commit/?id=3D649b747913d2b289e= 904b5f1d222af886acd209c >=20 > > The issue is that in case of open(path, O_NOFOLLOW), when path is naming > > a symlink, FreeBSD returns EMLINK error. On the other hand, the POSIX > > requirement is absolutely clear that it shall be ELOOP. >=20 > > I found FreeBSD commit r35088 that specifically changed the error code > > from the required ELOOP to EMLINK. I doubt that somebody can remember > > a reason for the change done more then 12 years ago. >=20 > In fact that change was done hours after the new ELOOP error. I don't think that POSIX knew about O_NOFOLLOW at that time, so peter@ properly predicted ELOOP, but some evil creature convinced him to change it to EMLINK. This is from 2004: http://pubs.opengroup.org/onlinepubs/009695399/functions/open.html and not a word about O_NOFOLLOW. PS. I'm voting with both hands to change it to ELOOP. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --ncSAzJYg3Aa9+CRW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk19G/IACgkQForvXbEpPzStAACgtodD99wJDrlF1HMRGnKG5QF1 T5oAn3pkoXgktTYsek/JXbrd1ne5L65/ =Nkcw -----END PGP SIGNATURE----- --ncSAzJYg3Aa9+CRW-- From owner-freebsd-standards@FreeBSD.ORG Mon Mar 14 11:07:10 2011 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4481106564A for ; Mon, 14 Mar 2011 11:07:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D1FFB8FC13 for ; Mon, 14 Mar 2011 11:07:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2EB79qW002689 for ; Mon, 14 Mar 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2EB7976002687 for freebsd-standards@FreeBSD.org; Mon, 14 Mar 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Mar 2011 11:07:09 GMT Message-Id: <201103141107.p2EB7976002687@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 11:07:10 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/154842 standards invalid request authenticator in the second and subseq o stand/150093 standards C++ std::locale support is broken a stand/149980 standards [libc] [patch] negative value integer to nanosleep(2) o stand/147210 standards xmmintrin.h and cstdlib conflicts with each other with o docs/143472 standards gethostname(3) references undefined value: HOST_NAME_M s stand/141705 standards [libc] [request] libc lacks cexp (and friends) o stand/130067 standards Wrong numeric limits in system headers? o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( o stand/56476 standards [patch] cd9660 unicode support simple hack o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44365 standards [headers] [patch] [request] introduce ulong and unchar a stand/41576 standards ln(1): replacing old dir-symlinks o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h s stand/24590 standards timezone function not compatible witn Single Unix Spec o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 35 problems total. From owner-freebsd-standards@FreeBSD.ORG Wed Mar 16 15:23:13 2011 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABCB41065672; Wed, 16 Mar 2011 15:23:13 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 921378FC17; Wed, 16 Mar 2011 15:23:13 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p2GFJcmt067202; Wed, 16 Mar 2011 08:19:38 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4D80D5E0.5080302@rawbw.com> Date: Wed, 16 Mar 2011 08:23:12 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: David Xu References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> In-Reply-To: <4D6B01DB.9090909@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-hackers@freebsd.org, standards@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 15:23:13 -0000 On 02/27/2011 18:00, David Xu wrote: > I think in normal case, pthread_cond_signal will wake up one thread, > but other events for example, UNIX signal and fork() may interrupt > a thread sleeping in kernel, and cause pthread_cond_wait to return > to userland, this is called spurious wakeup, and other events, I > can not think of yet, but I believe they exist. > Does this mean that pthread_cond_signal can also return EINTR? This isn't in pthread_cond_signal(3) either. Is this the case that all system calls should be assumed to be able to return EINTR or only those that have EINTR in their man pages? Yuri From owner-freebsd-standards@FreeBSD.ORG Thu Mar 17 01:54:07 2011 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA3BE1065673; Thu, 17 Mar 2011 01:54:07 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96A3B8FC12; Thu, 17 Mar 2011 01:54:07 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2H1s5xx023745; Thu, 17 Mar 2011 01:54:06 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D8169BF.6090503@freebsd.org> Date: Thu, 17 Mar 2011 09:54:07 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110127 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yuri References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> <4D80D5E0.5080302@rawbw.com> In-Reply-To: <4D80D5E0.5080302@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-hackers@freebsd.org, standards@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 01:54:07 -0000 On 2011/03/16 23:23, Yuri wrote: > On 02/27/2011 18:00, David Xu wrote: >> I think in normal case, pthread_cond_signal will wake up one thread, >> but other events for example, UNIX signal and fork() may interrupt >> a thread sleeping in kernel, and cause pthread_cond_wait to return >> to userland, this is called spurious wakeup, and other events, I >> can not think of yet, but I believe they exist. >> > > Does this mean that pthread_cond_signal can also return EINTR? This > isn't in pthread_cond_signal(3) either. > No, it will return zero, returning EINTR is not allowed. > Is this the case that all system calls should be assumed to be able to > return EINTR or only those that have EINTR in their man pages? > > Yuri > From owner-freebsd-standards@FreeBSD.ORG Thu Mar 17 02:43:32 2011 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23B64106566B; Thu, 17 Mar 2011 02:43:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 87B4A8FC12; Thu, 17 Mar 2011 02:43:31 +0000 (UTC) Received: by wyf23 with SMTP id 23so2508779wyf.13 for ; Wed, 16 Mar 2011 19:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b24KqvnzCJExZEUoM/fasCbkKId6Fkg1si3ONAGMfPs=; b=OvO3+Iudtfa+yimTcLOyVHHh8LGONdGZxtg5r0LvgppKQ8/W0Sd1QUNJwcpqFYExq3 FhcboQ361aeQIWlrv5Che78xQZ81CSOeJRfxIbkdBLSaET8T1U5+L5r0EoyUz9v91fVU XQvoa9WOyQXSoTLDZkQ5JFjY4zIgYAGrhx/lQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Wnoku/TFv5rjjqk3ArKc+8weczc5IzL/9WxUMT8YKGD1wTl2lKb33OqQYiuAN4UgeH VLYieTrRpx/q3ldv/PUJ71vT6n5XTBSw7n4v+Lub4gJzLw1I2SY7NX/69p7DUDXYr7vB /iGEiL2WG9M5CZe8gDsUfpzZKZUuF6aSlaEAY= MIME-Version: 1.0 Received: by 10.216.230.99 with SMTP id i77mr664626weq.100.1300328457639; Wed, 16 Mar 2011 19:20:57 -0700 (PDT) Received: by 10.216.173.142 with HTTP; Wed, 16 Mar 2011 19:20:57 -0700 (PDT) In-Reply-To: <4D8169BF.6090503@freebsd.org> References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> <4D80D5E0.5080302@rawbw.com> <4D8169BF.6090503@freebsd.org> Date: Wed, 16 Mar 2011 19:20:57 -0700 Message-ID: From: Garrett Cooper To: David Xu Content-Type: text/plain; charset=ISO-8859-1 Cc: Yuri , standards@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 02:43:32 -0000 On Wed, Mar 16, 2011 at 6:54 PM, David Xu wrote: > On 2011/03/16 23:23, Yuri wrote: >> On 02/27/2011 18:00, David Xu wrote: >>> I think in normal case, pthread_cond_signal will wake up one thread, >>> but other events for example, UNIX signal and fork() may interrupt >>> a thread sleeping in kernel, and cause pthread_cond_wait to return >>> to userland, this is called spurious wakeup, and other events, I >>> can not think of yet, but I believe they exist. >>> >> >> Does this mean that pthread_cond_signal can also return EINTR? This >> isn't in pthread_cond_signal(3) either. >> > > No, it will return zero, returning EINTR is not allowed. Adding some more context by adding the appropriate POSIX spec material... RETURN VALUE If successful, the pthread_cond_broadcast() and pthread_cond_signal() functions shall return zero; otherwise, an error number shall be returned to indicate the error. ERRORS The pthread_cond_broadcast() and pthread_cond_signal() function may fail if: [EINVAL] The value cond does not refer to an initialized condition variable. These functions shall not return an error code of [EINTR]. So yes, EINTR not being allowed is by design and this backs up what davidxu@ is stating above. Our manpage just doesn't explicitly call this requirement out, unlike a Linux manpage I dug up and the OpenGroup manpage. >> Is this the case that all system calls should be assumed to be able to >> return EINTR or only those that have EINTR in their man pages? Thanks, -Garrett From owner-freebsd-standards@FreeBSD.ORG Thu Mar 17 16:29:00 2011 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0E4E106566B; Thu, 17 Mar 2011 16:29:00 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7828FC0A; Thu, 17 Mar 2011 16:29:00 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p2HGPPum040853; Thu, 17 Mar 2011 09:25:25 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4D8236CB.5010000@rawbw.com> Date: Thu, 17 Mar 2011 09:28:59 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: Garrett Cooper References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> <4D80D5E0.5080302@rawbw.com> <4D8169BF.6090503@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, standards@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:29:00 -0000 On 03/16/2011 19:20, Garrett Cooper wrote: > So yes, EINTR not being allowed is by design and this backs up what > davidxu@ is stating above. Our manpage just doesn't explicitly call > this requirement out, unlike a Linux manpage I dug up and the > OpenGroup manpage. > I apologize for keeping asking, but David Xu mentioned before that signal can also be delivered at the same time and pthread_cond_signal will exit. Normally its EINTR (like for open(2)). But now you are saying that EINTR isn't allowed for pthread_cond_signal. So does this mean that signal can't be delivered during pthread_cond_signal, or it will just return 0? In the latter case, how can I distinguish signal delivery and successful return? Yuri From owner-freebsd-standards@FreeBSD.ORG Thu Mar 17 23:48:07 2011 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56681065670; Thu, 17 Mar 2011 23:48:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BE2148FC0C; Thu, 17 Mar 2011 23:48:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2HNm7oT059546; Thu, 17 Mar 2011 23:48:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2HNm7PH059542; Thu, 17 Mar 2011 23:48:07 GMT (envelope-from linimon) Date: Thu, 17 Mar 2011 23:48:07 GMT Message-Id: <201103172348.p2HNm7PH059542@freefall.freebsd.org> To: dfilter@FreeBSD.ORG, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-standards@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: standards/155643: Re: standards/104743: commit references a PR X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 23:48:08 -0000 Old Synopsis: Re: standard/104743: commit references a PR New Synopsis: Re: standards/104743: commit references a PR State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Thu Mar 17 23:47:33 UTC 2011 State-Changed-Why: Misfiled followup to standards/104743; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-standards Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 17 23:47:33 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=155643