From owner-freebsd-standards@FreeBSD.ORG Sun Aug 8 20:01:24 2010 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 8936F106566B for ; Sun, 8 Aug 2010 20:01:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 16D418FC12 for ; Sun, 8 Aug 2010 20:01:23 +0000 (UTC) Received: by bwz9 with SMTP id 9so1073104bwz.13 for ; Sun, 08 Aug 2010 13:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=PxZW19DnYR/ixPfy7KuFQrndsAERZ13Hotq/b+JfLHY=; b=TRRiuoMQw/ZKHNwtvCcAXphTtA1WiXiM6+d09Ei54zBwRP24St22y9TUbEw4mLxsa1 hmJWWgOhl+3Kc4Q7Fg43FOQb4LieFB2ytzWRJAPBPQp1psmSprj+tZ4gP1ng+y7Z+nWG pic4yQoz7QSuleAYVfoP6WURTGAgmjVQOW800= 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 :content-type:content-transfer-encoding; b=U1o+7eftynEWl6/HtTW9hkfvMtWHxKKZpDPFQBsmLcQooXljH78Y4fkY/UVKzPE03P nGaz0xsKTBTbvrJXBP6hlpW6as8eluTzDyzbc38cKvl1EtTDAA0jFEuNIOstz7FCl6FK XdJL3NAihb0ER+ninUQ/wZm03GA97OzT31V6U= MIME-Version: 1.0 Received: by 10.204.131.200 with SMTP id y8mr9986887bks.107.1281297677092; Sun, 08 Aug 2010 13:01:17 -0700 (PDT) Received: by 10.204.117.78 with HTTP; Sun, 8 Aug 2010 13:01:17 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Aug 2010 13:01:17 -0700 Message-ID: From: Garrett Cooper To: standards@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Confusion over wording in glob(3) 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, 08 Aug 2010 20:01:24 -0000 On Mon, Aug 2, 2010 at 12:35 AM, Garrett Cooper wrote: > =A0 =A0I have some question about the ambiguity of the ERRORS section in > our glob(3) manpage. > > POSIX states: > > ERRORS > > =A0 =A0The glob() function shall fail and return the corresponding value = if: > > =A0 =A0GLOB_ABORTED > =A0 =A0 =A0 =A0The scan was stopped because GLOB_ERR was set or (*errfunc= ()) > returned non-zero. > =A0 =A0GLOB_NOMATCH > =A0 =A0 =A0 =A0The pattern does not match any existing pathname, and > GLOB_NOCHECK was not set in flags. > =A0 =A0GLOB_NOSPACE > =A0 =A0 =A0 =A0An attempt to allocate memory failed. > > (Note that there's no mention of `errno'). > Our manpage states: > > =A0 =A0 If glob() terminates due to an error, it sets errno and returns o= ne of > =A0 =A0 the following non-zero constants, which are defined in the includ= e file > =A0 =A0 : > > =A0 =A0 GLOB_NOSPACE =A0An attempt to allocate memory failed, or if errno= was 0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 GLOB_LIMIT was specified in the flags= and pglob->gl_matchc > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 or more patterns were matched. > > =A0 =A0 GLOB_ABORTED =A0The scan was stopped because an error was encount= ered and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 either GLOB_ERR was set or (*errfunc)= () returned non-zero. > > =A0 =A0 GLOB_NOMATCH =A0The pattern did not match a pathname and GLOB_NOC= HECK was > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not set. > > (Note the mention of errno). > So far I've only been able to hit a sensical error case once by doing > the following (but that could have been a side-effect from a malloc(3) > failure in terms of finding malloc.conf -- don't know for sure). The > rest of the time I get errno =3D 0: > > $ cc -o test_glob test_glob.c > $ ln -f test_glob test_glob_nomatch > $ ./test_glob_nomatch > NOMATCH > glob(./test_glob_nomatch.*) didn't match: 0: Unknown error: 0 > > So I suppose my question is: should the confusing wording be removed > for clarity? Looking over the manpages a bit more closely, it might help if I had specified GLOB_ERR -- but it would help if that was spelled out more clearly in the manpage (I tend to skim to the bottom of manpages for the error and return code sections, so I missed that point). Thanks! -Garrett From owner-freebsd-standards@FreeBSD.ORG Mon Aug 9 11:07:05 2010 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 49BE01065677 for ; Mon, 9 Aug 2010 11:07:05 +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 3783E8FC25 for ; Mon, 9 Aug 2010 11:07:05 +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 o79B75MO049145 for ; Mon, 9 Aug 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o79B74fR049143 for freebsd-standards@FreeBSD.org; Mon, 9 Aug 2010 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Aug 2010 11:07:04 GMT Message-Id: <201008091107.o79B74fR049143@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, 09 Aug 2010 11:07:05 -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/147210 standards xmmintrin.h and cstdlib conflicts with each other with p stand/145517 standards POSIX getline() missing o stand/144231 standards bind/connect/sendto too strict about sockaddr length o stand/143358 standards [libm] nearbyint(3) raises spurious inexact exception o stand/142803 standards j0 Bessel function inaccurate near zeros of the functi 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/123688 standards POSIX standard changes in unistd.h and grp.h 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/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim 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/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm 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( s stand/62858 standards malloc(0) not C99 compliant 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 p stand/41576 standards ln(1): replacing old dir-symlinks o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s 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 42 problems total. From owner-freebsd-standards@FreeBSD.ORG Wed Aug 11 07:04:51 2010 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 647261065672 for ; Wed, 11 Aug 2010 07:04:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E4B5D8FC0A for ; Wed, 11 Aug 2010 07:04:50 +0000 (UTC) Received: by bwz9 with SMTP id 9so3126700bwz.13 for ; Wed, 11 Aug 2010 00:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VuFe51IVkh9E+OAbMcxCiIxKY8xNPcNhSG+7dcmlcnM=; b=SXZNnAXTOngoS+14KXW9wrlUV2ChxtLBijm7BAZjW/A+uJtzzQ5HKc4cxefY3XAQd9 zVNgAaJyGJfPL7s6fRug/gj5wXi439R6C5wBVkJaF/oPTCOIP9JfFABOwi490yyvAB9I M2aLlK0uwe+yae7HUcRh9JzG/b0Z2WB91DaFA= 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:content-transfer-encoding; b=xD1p7SbgliwkKGw8DrZeNu9Rnv7bh9ouqijHEHEPsVkRw+SMp5+UkcSJyg6p3T2Fmg 4dkem63gtw6H1bxU1BKUXvXYc4z/0MV4uBz/K1a73sxeoCLAydofOLlNhxbDXTGdSo8A ZxyR004YonXPqT+KUn0lkWF9bRbVbnDwxDqig= MIME-Version: 1.0 Received: by 10.204.175.1 with SMTP id v1mr4935931bkz.140.1281510289882; Wed, 11 Aug 2010 00:04:49 -0700 (PDT) Received: by 10.204.82.6 with HTTP; Wed, 11 Aug 2010 00:04:49 -0700 (PDT) In-Reply-To: <19537.46031.343891.856928@khavrinen.csail.mit.edu> References: <19537.40008.156802.846800@khavrinen.csail.mit.edu> <19537.46031.343891.856928@khavrinen.csail.mit.edu> Date: Wed, 11 Aug 2010 00:04:49 -0700 Message-ID: From: Garrett Cooper To: Garrett Wollman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: standards@freebsd.org Subject: Re: POSIX compliance issue with mmap(2) 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, 11 Aug 2010 07:04:51 -0000 On Thu, Jul 29, 2010 at 10:01 AM, Garrett Wollman w= rote: > <= said: > >> There are a number of opengroup manpages I've seen use the `shall >> fail' tort in the ERRORs sections -- some being connect(2), open(2), >> etc. I'll see if I can get clarification on whether or not there is >> any wiggle room if it states "shall fail if". > > "Shall" is a mandatory requirement; if it were optional, it would say > "may" instead. =A0(A conformance test has to include at least one test > for every instance of the word "shall" in the standard.) According to the Austin Group folks, shall is a very clear term [1] For an implementation that conforms to POSIX.1-2008, describes a feature or behavior that is mandatory. An application can rely on the existence of the feature or behavior. For an application or user, describes a behavior that is mandatory. should [1] is a different item entirely. So mmap(2) needs to be fixed. Shall I create a patch for this? Thanks, -Garrett [1] http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html