From owner-freebsd-standards@FreeBSD.ORG Mon Jun 10 11:06:56 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B096874 for ; Mon, 10 Jun 2013 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A0F111C9B for ; Mon, 10 Jun 2013 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5AB6uSO097120 for ; Mon, 10 Jun 2013 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5AB6uqY097118 for freebsd-standards@FreeBSD.org; Mon, 10 Jun 2013 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Jun 2013 11:06:56 GMT Message-Id: <201306101106.r5AB6uqY097118@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 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 11:06:56 -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/179248 standards A return value of telldir(3) only seekable for once o stand/177742 standards conflict of dd's bs= option with use of conv=sparse o stand/176683 standards catman pages shall be stored in /var (/usr/local/var,/ o stand/176412 standards newfs writes by default, compare to bsdlabel/disklabel o stand/175711 standards When the server has more than 3 days, rising interrupt o stand/175453 standards Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 o stand/174938 standards Problem statement: iSCSI target failure o stand/173421 standards [libc] [patch] strptime() accepts formats that should o stand/173087 standards pax(1) does not support the pax interchange format o stand/172805 standards Fix catopen(3)'s EINVAL usage and document EFTYPE o stand/172276 standards POSIX: {get,set}groups gidsetsize is u_int not int o stand/172215 standards localeconv() grouping appears not to match POSIX o stand/170403 standards wrong ntohs expression type tickling clang o stand/169697 standards syslogd(8) is not BOM aware o stand/166349 standards Support the assignment-allocation character for fscanf p stand/164787 standards dirfd() function not available when _POSIX_C_SOURCE is o kern/164674 standards [patch] [libc] vfprintf/vfwprintf return error (EOF) o o stand/162434 standards getaddrinfo: addrinfo.ai_family is an address family, o stand/150093 standards C++ std::locale support is broken 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/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 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 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 Tue Jun 11 17:52:51 2013 Return-Path: Delivered-To: freebsd-standards@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B72B96EF; Tue, 11 Jun 2013 17:52:51 +0000 (UTC) (envelope-from wollman@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 917DD1197; Tue, 11 Jun 2013 17:52:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5BHqpBF073139; Tue, 11 Jun 2013 17:52:51 GMT (envelope-from wollman@freefall.freebsd.org) Received: (from wollman@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5BHqoqQ073138; Tue, 11 Jun 2013 17:52:50 GMT (envelope-from wollman) Date: Tue, 11 Jun 2013 17:52:50 GMT Message-Id: <201306111752.r5BHqoqQ073138@freefall.freebsd.org> To: hongli@phusion.nl, wollman@FreeBSD.org, freebsd-standards@FreeBSD.org From: wollman@FreeBSD.org Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 17:52:51 -0000 Synopsis: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 State-Changed-From-To: open->patched State-Changed-By: wollman State-Changed-When: Tue Jun 11 17:51:49 UTC 2013 State-Changed-Why: Fixed in HEAD and stable/9, will be in 9.2 release. http://www.freebsd.org/cgi/query-pr.cgi?pr=175453 From owner-freebsd-standards@FreeBSD.ORG Tue Jun 11 21:40:07 2013 Return-Path: Delivered-To: freebsd-standards@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C8B3EA2 for ; Tue, 11 Jun 2013 21:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9921EA5 for ; Tue, 11 Jun 2013 21:40:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5BLe62q019921 for ; Tue, 11 Jun 2013 21:40:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5BLe6xb019920; Tue, 11 Jun 2013 21:40:06 GMT (envelope-from gnats) Date: Tue, 11 Jun 2013 21:40:06 GMT Message-Id: <201306112140.r5BLe6xb019920@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org Cc: From: Jilles Tjoelker Subject: Re: standards/179248: A return value of telldir(3) only seekable for once X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jilles Tjoelker List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 21:40:07 -0000 The following reply was made to PR standards/179248; it has been noted by GNATS. From: Jilles Tjoelker To: Akinori MUSHA Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: standards/179248: A return value of telldir(3) only seekable for once Date: Tue, 11 Jun 2013 23:29:53 +0200 On Mon, Jun 03, 2013 at 07:14:46AM +0000, Akinori MUSHA wrote: > >Number: 179248 > >Category: standards > >Synopsis: A return value of telldir(3) only seekable for once > [snip] > >Description: > Our implementation of telldir(3)/seekdir(3) is not POSIX compliant in > that a value obtained from telldir(3) is invalidated after calling > seekdir(3) and then readdir(3). > IEEE Std 1003.1, 2008/2013 says that only a call of rewinddir(3) may > invalidate the location values returned by telldir(3): > If the value of loc was not obtained from an earlier call to > telldir(), or if a call to rewinddir() occurred between the call > to telldir() and the call to seekdir(), the results of subsequent > calls to readdir() are unspecified. I think the problem is that telldir()/seekdir() want to return to the same directory entry within the block, instead of to the beginning of the block, while the required bits for the entry within the block are not available in telldir()'s return value. Some other platforms provide kernel support for this operation. The struct dirent has a field d_off which is the file offset of the next entry. It looks like the ino64 patches from Gleb Kurtsou add this functionality to the FreeBSD kernel. With this, telldir() returns the d_off value in the last dirent returned by readdir() (or 0) and seekdir() simply calls lseek(). As a result, a telldir()/seekdir() sequence may set the directory "backwards" a few entries even if it has been unmodified, because UFS truncates the offset to a block boundary. This may require a network filesystem to deny requests for a single directory entry at a time. Alternatively, UFS may replace the truncated bits with the number of directory entries to skip. This takes advantage of d_off being more like a "cookie" than a true file offset. The kernel may have a similar "out of bits" problem when an application with 32-bit long calls getdirentries(2) on an NFSv3 directory which returns 64-bit cookies, and also with unionfs and mount -o union. In the case of unionfs, the kernel appears to use some sort of state in the unionfs vnode and assumes that the directory cookies are otherwise unique enough. This likely causes problems if lseek() is used with a non-zero offset/cookie. In the case of mount -o union, the kernel "solves" the problem by irreversibly modifying the open file description to refer to the lower layer after the upper layer's entries have been read; the only way to deal with this in userland is to read the entire directory on a duplicate open file description (created with open(fd, ".", ...)) on opendir() and rewinddir() (bug: rewinddir() does not do this, violating POSIX's requirement that rewinddir() pick up changes made to the directory). > >Fix: > I don't have a quick fix for this, as it may need a revamp of how the > location thing is defined. > NetBSD seems to have a different implementation which doesn't have > this problem. > However, I'm not sure if theirs is flawless esp. wrt memory > management. NetBSD stores the (block, entry) pairs uniquely and for the life of the DIR object (perhaps discarding them upon rewinddir() as well). This means no memory is "leaked" per se but memory consumption on a DIR that has many telldir() calls is proportional to the number of entries in the directory. Also, a "proper" solution is possible if you are willing to accept that it does not work for all filesystems. Most filesystems leave some of the bits zero (particularly if there are 64 of them) which can then be used to store the entry number. However, a malloc-based solution is then still necessary for filesystems that do need all the bits or very large directories. -- Jilles Tjoelker From owner-freebsd-standards@FreeBSD.ORG Thu Jun 13 11:12:07 2013 Return-Path: Delivered-To: freebsd-standards@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C72BCD6; Thu, 13 Jun 2013 11:12:07 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 16CCF16E8; Thu, 13 Jun 2013 11:12:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5DBC69l078803; Thu, 13 Jun 2013 11:12:06 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5DBC66F078802; Thu, 13 Jun 2013 11:12:06 GMT (envelope-from gavin) Date: Thu, 13 Jun 2013 11:12:06 GMT Message-Id: <201306131112.r5DBC66F078802@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-standards@FreeBSD.org, freebsd-numerics@FreeBSD.org From: gavin@FreeBSD.org Subject: Re: standards/82654: C99 long double math functions are missing X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 11:12:07 -0000 Synopsis: C99 long double math functions are missing Responsible-Changed-From-To: freebsd-standards->freebsd-numerics Responsible-Changed-By: gavin Responsible-Changed-When: Thu Jun 13 11:09:50 UTC 2013 Responsible-Changed-Why: Over to -numerics. It looks like at least half of this has already made it into releases, and the other half is in head, so it may be that this PR can be put into "patched" state now. http://www.freebsd.org/cgi/query-pr.cgi?pr=82654 From owner-freebsd-standards@FreeBSD.ORG Fri Jun 14 06:53:58 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9392566C; Fri, 14 Jun 2013 06:53:58 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (50-196-151-174-static.hfc.comcastbusiness.net [50.196.151.174]) by mx1.freebsd.org (Postfix) with ESMTP id 79B81167E; Fri, 14 Jun 2013 06:53:57 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.7/8.14.2) with ESMTP id r5E6rvBI084983; Thu, 13 Jun 2013 23:53:57 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.7/8.14.2/Submit) id r5E6rvQ5084982; Thu, 13 Jun 2013 23:53:57 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 13 Jun 2013 23:53:57 -0700 From: David Schultz To: gavin@FreeBSD.org Subject: Re: standards/82654: C99 long double math functions are missing Message-ID: <20130614065357.GA84881@zim.MIT.EDU> References: <201306131112.r5DBC66F078802@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201306131112.r5DBC66F078802@freefall.freebsd.org> Cc: freebsd-numerics@FreeBSD.org, freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 06:53:58 -0000 On Thu, Jun 13, 2013, gavin@FreeBSD.org wrote: > Synopsis: C99 long double math functions are missing > > Responsible-Changed-From-To: freebsd-standards->freebsd-numerics > Responsible-Changed-By: gavin > Responsible-Changed-When: Thu Jun 13 11:09:50 UTC 2013 > Responsible-Changed-Why: > Over to -numerics. It looks like at least half of this has > already made it into releases, and the other half is in head, so > it may be that this PR can be put into "patched" state now. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=82654 I think someone mentioned wanting to keep this open as a tracking bug, although I now have a wiki page for tracking the status of this work, so it's probably fine to close. kargl@ should do the honors!