From owner-freebsd-standards@FreeBSD.ORG Mon Jan 20 11:06:54 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1951AF2 for ; Mon, 20 Jan 2014 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD23B1D7F for ; Mon, 20 Jan 2014 11:06:53 +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 s0KB6rEm088493 for ; Mon, 20 Jan 2014 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0KB6rOr088491 for freebsd-standards@FreeBSD.org; Mon, 20 Jan 2014 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Jan 2014 11:06:53 GMT Message-Id: <201401201106.s0KB6rOr088491@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.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 11:06:54 -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/185663 standards Bug in the libcxxrt version in FreeBSD 10.0: _ZTIDn no o stand/184694 standards gssapi.h does not define GSS_C_PRF_KEY_{FULL,PARTIAL} o stand/183654 standards FreeBSD 10 Beta2: Installer provided five times the am o stand/183652 standards make installkernel failure with installer provided ZFS 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 p 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/125751 standards man 3 pthread_getschedparam section ERRORS incomplete 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/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 46 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue Jan 21 08:50:07 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1FFB5A7 for ; Tue, 21 Jan 2014 08:50:07 +0000 (UTC) Received: from mail-oa0-x248.google.com (mail-oa0-x248.google.com [IPv6:2607:f8b0:4003:c02::248]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE34412EA for ; Tue, 21 Jan 2014 08:50:07 +0000 (UTC) Received: by mail-oa0-f72.google.com with SMTP id i4so7630539oah.11 for ; Tue, 21 Jan 2014 00:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:message-id:date:subject:from:to:content-type; bh=e0sYdkhF/0vzy5O9229uG9AEK50Yuq3pV46aY625Wp8=; b=eVCI6hkfRokUY2yosdnG34BZ28M2SSaiIPoe6k5pLpJuWECquixrgC1yE419L1nEx2 zBYqL3qzsynk8Vf0iG8FwXfrMN9LA8vSkic18LzJaGLNjOAo9NnhQkJ22jDVwLXLIg7L uQrPtlUE3yNpaZ4ijEaycy1rux7Zy+1C7tSzy/ggNn9x7agk0eSBD6rDhUbyEAiUp3ob loEDBuX1qj49oTCTcSLeN/LMtojO8KAmcuXvXL5OPhXZrkHYwFApeNuSvVlG833qYztw if/8oLwYfkS4o1yDzcViv++O5yGbUuu6gv4EkIzey/4wyrOYQcQrALG+OY0bOu0XFD7n 63Vg== MIME-Version: 1.0 X-Received: by 10.50.32.6 with SMTP id e6mr2003848igi.6.1390294206991; Tue, 21 Jan 2014 00:50:06 -0800 (PST) Message-ID: <047d7b10ce85575ec104f0771849@google.com> Date: Tue, 21 Jan 2014 08:50:06 +0000 Subject: www.freebsd.org From: Anna Garcia To: freebsd-standards@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 08:50:07 -0000 SGksDQoNCkkganVzdCB3YW50ZWQgdG8gc2VuZCB5b3UgYSBxdWljayBub3RlLiBXaXRoIGEgZmV3 IHNpbXBsZSBjaGFuZ2VzIHRvIG1ha2UNCnlvdXIgc2l0ZSBtb3JlIFNFTy1mcmllbmRseSBJkm0g c3VyZSB5b3UgY2FuIGNvbnZlcnQgbW9yZSB2aXNpdG9ycyBpbnRvDQpsZWFkcyBhbmQgZ2V0IGl0 IHBsYWNlZCBoaWdoZXIgaW4gdGhlIG9yZ2FuaWMgc2VhcmNoIHJlc3VsdHMsIGZvciBrZXl3b3Jk cw0KdGhhdCBtYXR0ZXIgdG8geW91IHRoZSBtb3N0Lg0KDQpXZSBhcmUgYW4gQXVzdHJhbGlhbiBi YXNlZCBjb21wYW55IHdpdGggYSBncmVhdCBpbi1ob3VzZSB0ZWNobmljYWwgdGVhbSB3aG8NCnJl YWxseSBrbm93IHRoZWlyIHN0dWZmIGFib3V0IHNlYXJjaCBlbmdpbmUgb3B0aW1pemF0aW9uLg0K DQpXb3VsZCB5b3UgbGlrZSBhIGJpdCBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGhvdyB0byBnaXZl IHlvdXIgd2Vic2l0ZSBhDQpib29zdCB3aXRoIGJldHRlciBTRU8/DQoNCkJlc3QgcmVnYXJkcywN Cg0KQW5uYSBHYXJjaWENClNFTy9XRUIgU3BlY2lhbGlzdA0KDQpbaW1hZ2U6IExpbmtlZEluXSBb aW1hZ2U6IEZhY2Vib29rXSBbaW1hZ2U6IFR3aXR0ZXJdIFtpbWFnZTogU2t5cGVdDQogICAgICAg ICAgICAgUyAgIEUgIE8gICAgICAgICAgICAqU2VhcmNoIEVuZ2luZSBPcHRpbWl6YXRpb24qDQoN CldlIHJlc3BlY3QgeW91ciBwcml2YWN5IGFuZCB3YW50IHRvIG1ha2Ugc3VyZSB5b3UgYXJlIGF3 YXJlIG9mIGEgZmV3DQp0aGluZ3MuIEJ5IHJlcGx5aW5nIHRvIHRoaXMgZW1haWwsIHlvdSBhdXRo b3JpemUgb3VyIEF1c3RyYWxpYW4gYWZmaWxpYXRlcw0KdGhhdCBjYW4gaGVscCB3aXRoIHlvdXIg cHJvamVjdCB0byBjYWxsIHlvdSBhdCB0aGUgbnVtYmVyIHlvdSBwcm92aWRlZCwgYW5kDQp5b3Ug dW5kZXJzdGFuZCB0aGF0IHRoZXkgbWF5IHVzZSBhdXRvbWF0ZWQgcGhvbmUgdGVjaG5vbG9neSB0 byBjYWxsIHlvdS4gQXQNCm5vIHRpbWUgYXJlIHlvdSByZXF1aXJlZCB0byBtYWtlIGEgcHVyY2hh c2UuDQo= From owner-freebsd-standards@FreeBSD.ORG Thu Jan 23 09:00:00 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9BD02CA for ; Thu, 23 Jan 2014 09:00:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A48C3145B for ; Thu, 23 Jan 2014 09:00:00 +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 s0N900BL056088 for ; Thu, 23 Jan 2014 09:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0N900TN056087; Thu, 23 Jan 2014 09:00:00 GMT (envelope-from gnats) Resent-Date: Thu, 23 Jan 2014 09:00:00 GMT Resent-Message-Id: <201401230900.s0N900TN056087@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Gennady Proskurin 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 B4F4A1B5 for ; Thu, 23 Jan 2014 08:58:59 +0000 (UTC) Received: from oldred.freebsd.org (oldred.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0F6D1448 for ; Thu, 23 Jan 2014 08:58:59 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id s0N8wwAw039916 for ; Thu, 23 Jan 2014 08:58:58 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id s0N8wwQB039907; Thu, 23 Jan 2014 08:58:58 GMT (envelope-from nobody) Message-Id: <201401230858.s0N8wwQB039907@oldred.freebsd.org> Date: Thu, 23 Jan 2014 08:58:58 GMT From: Gennady Proskurin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: standards/186028: incorrect return values for posix_fallocate() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 09:00:01 -0000 >Number: 186028 >Category: standards >Synopsis: incorrect return values for posix_fallocate() >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 23 09:00:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Gennady Proskurin >Release: FreeBSD 11.0-CURRENT >Organization: >Environment: FreeBSD gpr.nnz-home.ru 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r260472+743aa78(svn_head): Fri Jan 10 05:28:05 MSK 2014 gpr@gpr.nnz-home.ru:/usr/obj/usr/src/freebsd-head/sys/GPR amd64 >Description: In case of error, posix_fallocate() should return error code itself, but in FreeBSD it returns -1 and sets errno. Quote from standard: http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html RETURN VALUE Upon successful completion, posix_fallocate() shall return zero; otherwise, an error number shall be returned to indicate the error. Quote from freebsd man: RETURN VALUES If successful, posix_fallocate() returns zero. It returns -1 on failure, and sets errno to indicate the error. >How-To-Repeat: test program attached >Fix: Patch attached with submission follows: #include #include #include #include int main() { int ret; int err; errno = 0; ret = posix_fallocate(-1 /* emulate EBADF error */, 0, 1); err = errno; printf("return value : %i strerror: %s\n", ret, strerror(ret)); printf("errno : %i strerror: %s\n", err, strerror(err)); } >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Thu Jan 23 09:40:28 2014 Return-Path: Delivered-To: standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6981E7A; Thu, 23 Jan 2014 09:40:28 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 68537184F; Thu, 23 Jan 2014 09:40:25 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s0N9eHNO059334; Thu, 23 Jan 2014 11:40:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s0N9eHNO059334 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s0N9eHCT059332; Thu, 23 Jan 2014 11:40:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 23 Jan 2014 11:40:17 +0200 From: Konstantin Belousov To: Gennady Proskurin Subject: Re: standards/186028: incorrect return values for posix_fallocate() Message-ID: <20140123094017.GH24664@kib.kiev.ua> References: <201401230858.s0N8wwQB039907@oldred.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wayzTnRSUXKNfBqd" Content-Disposition: inline In-Reply-To: <201401230858.s0N8wwQB039907@oldred.freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: mdf@freebsd.org, standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 09:40:28 -0000 --wayzTnRSUXKNfBqd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 23, 2014 at 08:58:58AM +0000, Gennady Proskurin wrote: >=20 > >Number: 186028 > >Category: standards > >Synopsis: incorrect return values for posix_fallocate() > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-standards > >State: open > >Quarter: =20 > >Keywords: =20 > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Thu Jan 23 09:00:00 UTC 2014 > >Closed-Date: > >Last-Modified: > >Originator: Gennady Proskurin > >Release: FreeBSD 11.0-CURRENT > >Organization: > >Environment: > FreeBSD gpr.nnz-home.ru 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r260472+743a= a78(svn_head): Fri Jan 10 05:28:05 MSK 2014 gpr@gpr.nnz-home.ru:/usr/ob= j/usr/src/freebsd-head/sys/GPR amd64 > >Description: > In case of error, posix_fallocate() should return error code itself, but = in FreeBSD it returns -1 and sets errno. >=20 > Quote from standard: > http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.= html > RETURN VALUE > Upon successful completion, posix_fallocate() shall return zero; othe= rwise, an error number shall be returned to indicate the error. >=20 >=20 > Quote from freebsd man: > RETURN VALUES > If successful, posix_fallocate() returns zero. It returns -1 on fai= lure, > and sets errno to indicate the error. >=20 > >How-To-Repeat: > test program attached > >Fix: >=20 >=20 > Patch attached with submission follows: >=20 > #include > #include > #include > #include >=20 > int main() > { > int ret; > int err; >=20 > errno =3D 0; > ret =3D posix_fallocate(-1 /* emulate EBADF error */, 0, 1); > err =3D errno; > printf("return value : %i strerror: %s\n", ret, strerror(ret)); > printf("errno : %i strerror: %s\n", err, strerror(err)); > } >=20 Indeed. Linux also seems to have the conforming behaviour, according to their man page, which also explicitely states that errno is not set. Try this. diff --git a/lib/libc/sys/posix_fallocate.2 b/lib/libc/sys/posix_fallocate.2 index 087c68c..ee6fcc4 100644 --- a/lib/libc/sys/posix_fallocate.2 +++ b/lib/libc/sys/posix_fallocate.2 @@ -83,9 +83,9 @@ that reduces the file size to a size smaller than If successful, .Fn posix_fallocate returns zero. -It returns -1 on failure, and sets +It returns error on failure, without setting .Va errno -to indicate the error. +variable. .Sh ERRORS Possible failure conditions: .Bl -tag -width Er diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index 719a057..e4ffbe4 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -2995,8 +2995,9 @@ freebsd32_posix_fallocate(struct thread *td, struct freebsd32_posix_fallocate_args *uap) { =20 - return (kern_posix_fallocate(td, uap->fd, - PAIR32TO64(off_t, uap->offset), PAIR32TO64(off_t, uap->len))); + td->td_retval[0] =3D kern_posix_fallocate(td, uap->fd, + PAIR32TO64(off_t, uap->offset), PAIR32TO64(off_t, uap->len)); + return (0); } =20 int diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index dbad1ae..b864c90 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -4584,7 +4584,9 @@ int sys_posix_fallocate(struct thread *td, struct posix_fallocate_args *uap) { =20 - return (kern_posix_fallocate(td, uap->fd, uap->offset, uap->len)); + td->td_retval[0] =3D kern_posix_fallocate(td, uap->fd, uap->offset, + uap->len); + return (0); } =20 /* --wayzTnRSUXKNfBqd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJS4OOAAAoJEJDCuSvBvK1BlUMP/1Uf92S2nvI0nhGf7AzT230Z ZcfI7jZ0XoKP3hCySgYBJOarhfNpYjNtBX4k8IAb50XRw/+r3RHhLDGXXvPFwt3H L1EMLQhipDpSErXUHp0ndsURCRH3DayaAPY7i7nwf0GqGCFgmbY6U1pMfzpgTfDc MrQNFVH3lwXM0hDHihzZqFxFYoB1XULbUB+GGS3b2waYBvRfuzYUswYSr18JNrrj VPTv5br7rwjUxqO+Jqr4vn39B22UsHRVp9Z4y2c03/I1+RlXoN7NcpgS1yKLwtr0 StQ3yn46IcvkWsaqSXm8amZ7c+dWQB5y/DZt24gWqPtfDylO+o3XEbr+RYFpTGyo sawuL2xaVwPLMYiIB24DJo8ajs6ePmQyHYr/2R0Gsac+D7774k61Z5IAuefBXw8I qGqMID+rsFiIbC6Amdbu1UV94MSj2vshQtNcnO2IsJk/XpYMR8QpLdXreDFPVN1B pkmuBhS4yUEPhOmsx33kvzOVOZ1Tkx9V3VLyR+LWd5kD/c3eWiVClV760/Vxyi9k tjEZjytKdobKo7scGwkpusqWaAloo57J1+rD61Wqgjb1ggeCtR1/igXzkVkAVKoS 1LKNRr90pRfxariyHqMrJp8Fvx6lKmlMe++ExAgYumWzV6tpVAZ+pCyeSwGNZPne lEYSHiB9lLSn8569fKpb =5ox1 -----END PGP SIGNATURE----- --wayzTnRSUXKNfBqd-- From owner-freebsd-standards@FreeBSD.ORG Thu Jan 23 14:36:16 2014 Return-Path: Delivered-To: standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FF8A2BC; Thu, 23 Jan 2014 14:36:16 +0000 (UTC) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id 48861149E; Thu, 23 Jan 2014 14:36:15 +0000 (UTC) Received: from f295.i.mail.ru (f295.i.mail.ru [217.69.138.195]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id F416733117A8; Thu, 23 Jan 2014 18:34:48 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:Mime-Version:Subject:Cc:To:From; bh=L3YnxWhZdh4XgF17492pc50XjqUnUReW5NA3QQc+Q5o=; b=bKU6Dt9rn/nu/Y4OHgpqXN8mXiqtpZzoELUCowIh/16C1SHsC9m4yz1NeeaGnJSryIwNDk0QsXbeHwGGzAgpcVVgXlHRhy91/tTJYfgP3jBOXUqGO9d0e6zmRcaPDa1YSNMq3v/PyrZ67O1v7Zmls3eaEwg+8fnvFjGV9f88rCE=; Received: from mail by f295.i.mail.ru with local (envelope-from ) id 1W6LMc-00022W-TY; Thu, 23 Jan 2014 18:34:39 +0400 Received: from [93.189.151.52] by e.mail.ru with HTTP; Thu, 23 Jan 2014 18:34:38 +0400 From: =?UTF-8?B?R2VubmFkeSBQcm9za3VyaW4=?= To: =?UTF-8?B?S29uc3RhbnRpbiBCZWxvdXNvdg==?= Subject: =?UTF-8?B?UmVbMl06IHN0YW5kYXJkcy8xODYwMjg6IGluY29ycmVjdCByZXR1cm4gdmFs?= =?UTF-8?B?dWVzIGZvciBwb3NpeF9mYWxsb2NhdGUoKQ==?= Mime-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [93.189.151.52] Date: Thu, 23 Jan 2014 18:34:38 +0400 X-Priority: 3 (Normal) Message-ID: <1390487678.53626142@f295.i.mail.ru> X-Mras: Ok X-Spam: undefined In-Reply-To: <20140123094017.GH24664@kib.kiev.ua> References: <201401230858.s0N8wwQB039907@oldred.freebsd.org> <20140123094017.GH24664@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: mdf@freebsd.org, standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: =?UTF-8?B?R2VubmFkeSBQcm9za3VyaW4=?= List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 14:36:16 -0000 IFRoaXMgcGF0Y2ggZml4ZXMgYnVnIGZvciBtZSwgZnJlZWJzZDMyIHZlcnNpb24gYWxzbyB3b3Jr cy4KVGhhbmsgeW91LgoK0KfQtdGC0LLQtdGA0LMsIDIzINGP0L3QstCw0YDRjyAyMDE0LCAxMTo0 MCArMDI6MDAg0L7RgiBLb25zdGFudGluIEJlbG91c292IDxrb3N0aWtiZWxAZ21haWwuY29tPjoK Pk9uIFRodSwgSmFuIDIzLCAyMDE0IGF0IDA4OjU4OjU4QU0gKzAwMDAsIEdlbm5hZHkgUHJvc2t1 cmluIHdyb3RlOgo+PiAKPj4gPk51bWJlcjogICAgICAgICAxODYwMjgKPj4gPkNhdGVnb3J5OiAg ICAgICBzdGFuZGFyZHMKPj4gPlN5bm9wc2lzOiAgICAgICBpbmNvcnJlY3QgcmV0dXJuIHZhbHVl cyBmb3IgcG9zaXhfZmFsbG9jYXRlKCkKPj4gPkNvbmZpZGVudGlhbDogICBubwo+PiA+U2V2ZXJp dHk6ICAgICAgIG5vbi1jcml0aWNhbAo+PiA+UHJpb3JpdHk6ICAgICAgIGxvdwo+PiA+UmVzcG9u c2libGU6ICAgIGZyZWVic2Qtc3RhbmRhcmRzCj4+ID5TdGF0ZTogICAgICAgICAgb3Blbgo+PiA+ UXVhcnRlcjogCj4+ID5LZXl3b3JkczogCj4+ID5EYXRlLVJlcXVpcmVkOgo+PiA+Q2xhc3M6ICAg ICAgICAgIHN3LWJ1Zwo+PiA+U3VibWl0dGVyLUlkOiAgIGN1cnJlbnQtdXNlcnMKPj4gPkFycml2 YWwtRGF0ZTogICBUaHUgSmFuIDIzIDA5OjAwOjAwIFVUQyAyMDE0Cj4+ID5DbG9zZWQtRGF0ZToK Pj4gPkxhc3QtTW9kaWZpZWQ6Cj4+ID5PcmlnaW5hdG9yOiAgICAgR2VubmFkeSBQcm9za3VyaW4K Pj4gPlJlbGVhc2U6ICAgICAgICBGcmVlQlNEIDExLjAtQ1VSUkVOVAo+PiA+T3JnYW5pemF0aW9u Ogo+PiA+RW52aXJvbm1lbnQ6Cj4+IEZyZWVCU0QgZ3ByLm5uei1ob21lLnJ1IDExLjAtQ1VSUkVO VCBGcmVlQlNEIDExLjAtQ1VSUkVOVCAjMCByMjYwNDcyKzc0M2FhNzgoc3ZuX2hlYWQpOiBGcmkg SmFuIDEwIDA1OjI4OjA1IE1TSyAyMDE0ICAgICBncHJAZ3ByLm5uei1ob21lLnJ1Oi91c3Ivb2Jq L3Vzci9zcmMvZnJlZWJzZC1oZWFkL3N5cy9HUFIgIGFtZDY0Cj4+ID5EZXNjcmlwdGlvbjoKPj4g SW4gY2FzZSBvZiBlcnJvciwgcG9zaXhfZmFsbG9jYXRlKCkgc2hvdWxkIHJldHVybiBlcnJvciBj b2RlIGl0c2VsZiwgYnV0IGluIEZyZWVCU0QgaXQgcmV0dXJucyAtMSBhbmQgc2V0cyBlcnJuby4K Pj4gCj4+IFF1b3RlIGZyb20gc3RhbmRhcmQ6Cj4+ICBodHRwOi8vcHVicy5vcGVuZ3JvdXAub3Jn L29ubGluZXB1YnMvMDA5Njk1Mzk5L2Z1bmN0aW9ucy9wb3NpeF9mYWxsb2NhdGUuaHRtbAo+PiBS RVRVUk4gVkFMVUUKPj4gICAgIFVwb24gc3VjY2Vzc2Z1bCBjb21wbGV0aW9uLCBwb3NpeF9mYWxs b2NhdGUoKSBzaGFsbCByZXR1cm4gemVybzsgb3RoZXJ3aXNlLCBhbiBlcnJvciBudW1iZXIgc2hh bGwgYmUgcmV0dXJuZWQgdG8gaW5kaWNhdGUgdGhlIGVycm9yLgo+PiAKPj4gCj4+IFF1b3RlIGZy b20gZnJlZWJzZCBtYW46Cj4+IFJFVFVSTiBWQUxVRVMKPj4gICAgICBJZiBzdWNjZXNzZnVsLCBw b3NpeF9mYWxsb2NhdGUoKSByZXR1cm5zIHplcm8uICBJdCByZXR1cm5zIC0xIG9uIGZhaWx1cmUs Cj4+ICAgICAgYW5kIHNldHMgZXJybm8gdG8gaW5kaWNhdGUgdGhlIGVycm9yLgo+PiAKPj4gPkhv dy1Uby1SZXBlYXQ6Cj4+IHRlc3QgcHJvZ3JhbSBhdHRhY2hlZAo+PiA+Rml4Ogo+PiAKPj4gCj4+ IFBhdGNoIGF0dGFjaGVkIHdpdGggc3VibWlzc2lvbiBmb2xsb3dzOgo+PiAKPj4gI2luY2x1ZGUg PGZjbnRsLmg+Cj4+ICNpbmNsdWRlIDxlcnJuby5oPgo+PiAjaW5jbHVkZSA8c3RyaW5nLmg+Cj4+ ICNpbmNsdWRlIDxzdGRpby5oPgo+PiAKPj4gaW50IG1haW4oKQo+PiB7Cj4+IAlpbnQgcmV0Owo+ PiAJaW50IGVycjsKPj4gCj4+IAllcnJubyA9IDA7Cj4+IAlyZXQgPSBwb3NpeF9mYWxsb2NhdGUo LTEgLyogZW11bGF0ZSBFQkFERiBlcnJvciAqLywgMCwgMSk7Cj4+IAllcnIgPSBlcnJubzsKPj4g CXByaW50ZigicmV0dXJuIHZhbHVlIDogJWkgICBzdHJlcnJvcjogJXNcbiIsIHJldCwgc3RyZXJy b3IocmV0KSk7Cj4+IAlwcmludGYoImVycm5vICAgICAgICA6ICVpICAgc3RyZXJyb3I6ICVzXG4i LCBlcnIsIHN0cmVycm9yKGVycikpOwo+PiB9Cj4+IAo+Cj5JbmRlZWQuICBMaW51eCBhbHNvIHNl ZW1zIHRvIGhhdmUgdGhlIGNvbmZvcm1pbmcgYmVoYXZpb3VyLCBhY2NvcmRpbmcKPnRvIHRoZWly IG1hbiBwYWdlLCB3aGljaCBhbHNvIGV4cGxpY2l0ZWx5IHN0YXRlcyB0aGF0IGVycm5vIGlzIG5v dCBzZXQuCj4KPlRyeSB0aGlzLgo+Cj5kaWZmIC0tZ2l0IGEvbGliL2xpYmMvc3lzL3Bvc2l4X2Zh bGxvY2F0ZS4yIGIvbGliL2xpYmMvc3lzL3Bvc2l4X2ZhbGxvY2F0ZS4yCj5pbmRleCAwODdjNjhj Li5lZTZmY2M0IDEwMDY0NAo+LS0tIGEvbGliL2xpYmMvc3lzL3Bvc2l4X2ZhbGxvY2F0ZS4yCj4r KysgYi9saWIvbGliYy9zeXMvcG9zaXhfZmFsbG9jYXRlLjIKPkBAIC04Myw5ICs4Myw5IEBAIHRo YXQgcmVkdWNlcyB0aGUgZmlsZSBzaXplIHRvIGEgc2l6ZSBzbWFsbGVyIHRoYW4KPsKgSWYgc3Vj Y2Vzc2Z1bCwKPsKgLkZuIHBvc2l4X2ZhbGxvY2F0ZQo+wqByZXR1cm5zIHplcm8uCj4tSXQgcmV0 dXJucyAtMSBvbiBmYWlsdXJlLCBhbmQgc2V0cwo+K0l0IHJldHVybnMgZXJyb3Igb24gZmFpbHVy ZSwgd2l0aG91dCBzZXR0aW5nCj7CoC5WYSBlcnJubwo+LXRvIGluZGljYXRlIHRoZSBlcnJvci4K Pit2YXJpYWJsZS4KPsKgLlNoIEVSUk9SUwo+wqBQb3NzaWJsZSBmYWlsdXJlIGNvbmRpdGlvbnM6 Cj7CoC5CbCAtdGFnIC13aWR0aCBFcgo+ZGlmZiAtLWdpdCBhL3N5cy9jb21wYXQvZnJlZWJzZDMy L2ZyZWVic2QzMl9taXNjLmMgYi9zeXMvY29tcGF0L2ZyZWVic2QzMi9mcmVlYnNkMzJfbWlzYy5j Cj5pbmRleCA3MTlhMDU3Li5lNGZmYmU0IDEwMDY0NAo+LS0tIGEvc3lzL2NvbXBhdC9mcmVlYnNk MzIvZnJlZWJzZDMyX21pc2MuYwo+KysrIGIvc3lzL2NvbXBhdC9mcmVlYnNkMzIvZnJlZWJzZDMy X21pc2MuYwo+QEAgLTI5OTUsOCArMjk5NSw5IEBAIGZyZWVic2QzMl9wb3NpeF9mYWxsb2NhdGUo c3RydWN0IHRocmVhZCAqdGQsCj7CoMKgwqDCoMKgc3RydWN0IGZyZWVic2QzMl9wb3NpeF9mYWxs b2NhdGVfYXJncyAqdWFwKQo+wqB7Cj7CoAo+LQlyZXR1cm4gKGtlcm5fcG9zaXhfZmFsbG9jYXRl KHRkLCB1YXAtPmZkLAo+LQkgICAgUEFJUjMyVE82NChvZmZfdCwgdWFwLT5vZmZzZXQpLCBQQUlS MzJUTzY0KG9mZl90LCB1YXAtPmxlbikpKTsKPisJdGQtPnRkX3JldHZhbFswXSA9IGtlcm5fcG9z aXhfZmFsbG9jYXRlKHRkLCB1YXAtPmZkLAo+KwkgICAgUEFJUjMyVE82NChvZmZfdCwgdWFwLT5v ZmZzZXQpLCBQQUlSMzJUTzY0KG9mZl90LCB1YXAtPmxlbikpOwo+KwlyZXR1cm4gKDApOwo+wqB9 Cj7CoAo+wqBpbnQKPmRpZmYgLS1naXQgYS9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYyBiL3N5cy9r ZXJuL3Zmc19zeXNjYWxscy5jCj5pbmRleCBkYmFkMWFlLi5iODY0YzkwIDEwMDY0NAo+LS0tIGEv c3lzL2tlcm4vdmZzX3N5c2NhbGxzLmMKPisrKyBiL3N5cy9rZXJuL3Zmc19zeXNjYWxscy5jCj5A QCAtNDU4NCw3ICs0NTg0LDkgQEAgaW50Cj7CoHN5c19wb3NpeF9mYWxsb2NhdGUoc3RydWN0IHRo cmVhZCAqdGQsIHN0cnVjdCBwb3NpeF9mYWxsb2NhdGVfYXJncyAqdWFwKQo+wqB7Cj7CoAo+LQly ZXR1cm4gKGtlcm5fcG9zaXhfZmFsbG9jYXRlKHRkLCB1YXAtPmZkLCB1YXAtPm9mZnNldCwgdWFw LT5sZW4pKTsKPisJdGQtPnRkX3JldHZhbFswXSA9IGtlcm5fcG9zaXhfZmFsbG9jYXRlKHRkLCB1 YXAtPmZkLCB1YXAtPm9mZnNldCwKPisJICAgIHVhcC0+bGVuKTsKPisJcmV0dXJuICgwKTsKPsKg fQo+wqAKPsKgLyoKPgoKCi0tLQo= From owner-freebsd-standards@FreeBSD.ORG Thu Jan 23 15:09:10 2014 Return-Path: Delivered-To: standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10C705D9; Thu, 23 Jan 2014 15:09:10 +0000 (UTC) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 96240174F; Thu, 23 Jan 2014 15:09:09 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 92EBE10408B6; Fri, 24 Jan 2014 02:08:59 +1100 (EST) Date: Fri, 24 Jan 2014 02:08:54 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: standards/186028: incorrect return values for posix_fallocate() In-Reply-To: <20140123094017.GH24664@kib.kiev.ua> Message-ID: <20140124014043.T879@besplex.bde.org> References: <201401230858.s0N8wwQB039907@oldred.freebsd.org> <20140123094017.GH24664@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=Wu4Sb7vv c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=1FcmvNfKhqQA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=3BHb2PuD7wgA:10 a=eKQI6xHjb1eDkzikO7sA:9 a=QAnm8XVNnMn8zPeX:21 a=cVWQ5MPqDhCTD4Dt:21 a=CjuIK1q_8ugA:10 Cc: Gennady Proskurin , mdf@FreeBSD.org, standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 15:09:10 -0000 On Thu, 23 Jan 2014, Konstantin Belousov wrote: > Indeed. Linux also seems to have the conforming behaviour, according > to their man page, which also explicitely states that errno is not set. > > Try this. > > diff --git a/lib/libc/sys/posix_fallocate.2 b/lib/libc/sys/posix_fallocate.2 > index 087c68c..ee6fcc4 100644 > --- a/lib/libc/sys/posix_fallocate.2 > +++ b/lib/libc/sys/posix_fallocate.2 > @@ -83,9 +83,9 @@ that reduces the file size to a size smaller than > If successful, > .Fn posix_fallocate > returns zero. > -It returns -1 on failure, and sets > +It returns error on failure, without setting > .Va errno > -to indicate the error. > +variable. "returns error" is hard to parse. Only values can be returned. The old text would have had a style bug if it had been correct. Normal man pages use the mdoc markup ".Rv -std" instead of repeating the above boilerplate ad nauseum to describe standard error handling. In libc/sys, the macro is used in 106 man pages and the style bug is used in about 50 man pages. > .Sh ERRORS > Possible failure conditions: This section is not quite so hard to parse. It uses standard wording except for the above clause. The standard wording is adapted to returning the error code in errno. Only the above clause gives a different meaning to the markup of error codes, and it is incomplete for that. The standard wording seems to be broken too. The markup should be described in somewhere like intro(2) or errno(2) (errno(2) is just a link to intro(2)), but these man pages don't even contain a markup chracter. The markup is that square brackets around an error number EFOO normally mean that: - when the function fails for the reason given by the description at the right of [EFOO], then errno is set to EFOO This only applies for standard error handling. For posix_fallocate(), [EFOO] now means that EFOO is returned on failure under the condition described to the right of it. If [EFOO] were actually documented, then its documention would probably only apply to standard error handling so would become wrong when the markup is abused for something else. POSIX uses the following wording (in a 2001 draft): % 28228 RETURN VALUE % 28229 Upon successful completion, posix_fallocate( ) shall return zero; otherwise, an error number shall % 28230 be returned to indicate the error. This is OK. % 28231 ERRORS % 28232 The posix_fallocate( ) function shall fail if: % 28233 [EBADF] The fd argument is not a valid file descriptor. % ... This is more broken than in FreeBSD, because there is no extra clause to give a hint that the standard meaning doesn't apply. I couldn't find where POSIX defines the markup for errno numbers. It formally defines 'Brackets'. I could find where it formally defines the markup for limits. It is sloppy and uses the markup before defining it even for limits. C99 doesn't use any markup for errno numbers, but laboriously describes the setting of errno using English sentences. This is not too bad since C99 has a whole 3 error numbers (EDOM, ERANGE, and the newfangled EILSEQ) and most of its functions don't set errno. Bruce From owner-freebsd-standards@FreeBSD.ORG Thu Jan 23 15:36:22 2014 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 152A81BC for ; Thu, 23 Jan 2014 15:36:22 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C4B1919E5 for ; Thu, 23 Jan 2014 15:36:21 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id i13so2330620qae.41 for ; Thu, 23 Jan 2014 07:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ghiAknQiGTdHij77VQhtkUc+jMpWiTfgZbs4wO8gVro=; b=GnV7Ab8ZPDyqh3V3jnFyzTICAuYa+sXoESJVO7WSiVMnrReI6Ic+OZzYuPz6zLf0is p4unZvGk2dKCYKEixPZzmmUnwFfAmmyZFNhBPtqFysuJ7EqE07k25I0xSG0Os4Aa7P1a DowzMukFN8Z/VIlIleNPZrjvBN15rS7BmxI4nRUN3W1Uhy12H73JmnKuHwlzOJSmEGLx AtKauqDZaS/yPZioaNJn3HXBo/cDf85vZnU035TCWIFwcATXzY5dQ9F91ZG/F4uSSepk 5UUr6xXsjK0I5Y0P/bOLxwTVRML7PkjHI+NP+pa3c9zgxAFyDzUbMw1mGADk8/WpNzgq lClw== MIME-Version: 1.0 X-Received: by 10.224.70.84 with SMTP id c20mr12298857qaj.48.1390491380995; Thu, 23 Jan 2014 07:36:20 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.229.216.135 with HTTP; Thu, 23 Jan 2014 07:36:20 -0800 (PST) In-Reply-To: <20140124014043.T879@besplex.bde.org> References: <201401230858.s0N8wwQB039907@oldred.freebsd.org> <20140123094017.GH24664@kib.kiev.ua> <20140124014043.T879@besplex.bde.org> Date: Thu, 23 Jan 2014 07:36:20 -0800 X-Google-Sender-Auth: IHDceQKachnN1iloWuvbKFW8x4w Message-ID: Subject: Re: standards/186028: incorrect return values for posix_fallocate() From: Matthew Fleming To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Gennady Proskurin , standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 15:36:22 -0000 On Thu, Jan 23, 2014 at 7:08 AM, Bruce Evans wrote: > On Thu, 23 Jan 2014, Konstantin Belousov wrote: > > Indeed. Linux also seems to have the conforming behaviour, according >> to their man page, which also explicitely states that errno is not set. >> >> Try this. >> >> diff --git a/lib/libc/sys/posix_fallocate.2 b/lib/libc/sys/posix_ >> fallocate.2 >> index 087c68c..ee6fcc4 100644 >> --- a/lib/libc/sys/posix_fallocate.2 >> +++ b/lib/libc/sys/posix_fallocate.2 >> @@ -83,9 +83,9 @@ that reduces the file size to a size smaller than >> If successful, >> .Fn posix_fallocate >> returns zero. >> -It returns -1 on failure, and sets >> +It returns error on failure, without setting >> .Va errno >> -to indicate the error. >> +variable. >> > > "returns error" is hard to parse. Only values can be returned. > > The old text would have had a style bug if it had been correct. Normal > man pages use the mdoc markup ".Rv -std" instead of repeating the above > boilerplate ad nauseum to describe standard error handling. In libc/sys, > the macro is used in 106 man pages and the style bug is used in about > 50 man pages. Oops! I guess I didn't read the POSIX spec very carefully; my mental model is that only the pthread_* functions directly return the error, and others follow the old UNIX behaviour of returning -1 and setting errno. Anyways, the patch looks fine to me. Sorry for any errors in the man page as well; I never was able to find a guide to all the various mdoc macros so I had to work from examples. Cheers, matthew From owner-freebsd-standards@FreeBSD.ORG Thu Jan 23 21:20:28 2014 Return-Path: Delivered-To: standards@freebsd.org 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 561FEAA9; Thu, 23 Jan 2014 21:20:28 +0000 (UTC) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0C6F61D3A; Thu, 23 Jan 2014 21:20:27 +0000 (UTC) Received: from [194.32.164.24] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id s0NLKHPk011304; Thu, 23 Jan 2014 21:20:17 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: standards/186028: incorrect return values for posix_fallocate() From: Bob Bishop In-Reply-To: <20140123094017.GH24664@kib.kiev.ua> Date: Thu, 23 Jan 2014 21:20:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201401230858.s0N8wwQB039907@oldred.freebsd.org> <20140123094017.GH24664@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1827) Cc: Gennady Proskurin , mdf@freebsd.org, standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:20:28 -0000 Hi, On 23 Jan 2014, at 09:40, Konstantin Belousov = wrote: > On Thu, Jan 23, 2014 at 08:58:58AM +0000, Gennady Proskurin wrote: >>=20 >>> Number: 186028 >>> Category: standards >>> Synopsis: incorrect return values for posix_fallocate() >>> Confidential: no >>> Severity: non-critical >>> Priority: low >>> Responsible: freebsd-standards >>> State: open >>> Quarter: =20 >>> Keywords: =20 >>> Date-Required: >>> Class: sw-bug >>> Submitter-Id: current-users >>> Arrival-Date: Thu Jan 23 09:00:00 UTC 2014 >>> Closed-Date: >>> Last-Modified: >>> Originator: Gennady Proskurin >>> Release: FreeBSD 11.0-CURRENT >>> Organization: >>> Environment: >> FreeBSD gpr.nnz-home.ru 11.0-CURRENT FreeBSD 11.0-CURRENT #0 = r260472+743aa78(svn_head): Fri Jan 10 05:28:05 MSK 2014 = gpr@gpr.nnz-home.ru:/usr/obj/usr/src/freebsd-head/sys/GPR amd64 >>> Description: >> In case of error, posix_fallocate() should return error code itself, = but in FreeBSD it returns -1 and sets errno. FWIW at least posix_madvise() and posix_fadvise() have the same problem. >> Quote from standard: >> = http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.h= tml >> RETURN VALUE >> Upon successful completion, posix_fallocate() shall return zero; = otherwise, an error number shall be returned to indicate the error. >>=20 >>=20 >> Quote from freebsd man: >> RETURN VALUES >> If successful, posix_fallocate() returns zero. It returns -1 on = failure, >> and sets errno to indicate the error. >>=20 >>> How-To-Repeat: >> test program attached >>> Fix: >>=20 >>=20 >> Patch attached with submission follows: >>=20 >> #include >> #include >> #include >> #include >>=20 >> int main() >> { >> int ret; >> int err; >>=20 >> errno =3D 0; >> ret =3D posix_fallocate(-1 /* emulate EBADF error */, 0, 1); >> err =3D errno; >> printf("return value : %i strerror: %s\n", ret, = strerror(ret)); >> printf("errno : %i strerror: %s\n", err, = strerror(err)); >> } >>=20 >=20 > Indeed. Linux also seems to have the conforming behaviour, according > to their man page, which also explicitely states that errno is not = set. >=20 > Try this. >=20 > diff --git a/lib/libc/sys/posix_fallocate.2 = b/lib/libc/sys/posix_fallocate.2 > index 087c68c..ee6fcc4 100644 > --- a/lib/libc/sys/posix_fallocate.2 > +++ b/lib/libc/sys/posix_fallocate.2 > @@ -83,9 +83,9 @@ that reduces the file size to a size smaller than > If successful, > .Fn posix_fallocate > returns zero. > -It returns -1 on failure, and sets > +It returns error on failure, without setting > .Va errno > -to indicate the error. > +variable. > .Sh ERRORS > Possible failure conditions: > .Bl -tag -width Er > diff --git a/sys/compat/freebsd32/freebsd32_misc.c = b/sys/compat/freebsd32/freebsd32_misc.c > index 719a057..e4ffbe4 100644 > --- a/sys/compat/freebsd32/freebsd32_misc.c > +++ b/sys/compat/freebsd32/freebsd32_misc.c > @@ -2995,8 +2995,9 @@ freebsd32_posix_fallocate(struct thread *td, > struct freebsd32_posix_fallocate_args *uap) > { >=20 > - return (kern_posix_fallocate(td, uap->fd, > - PAIR32TO64(off_t, uap->offset), PAIR32TO64(off_t, = uap->len))); > + td->td_retval[0] =3D kern_posix_fallocate(td, uap->fd, > + PAIR32TO64(off_t, uap->offset), PAIR32TO64(off_t, = uap->len)); > + return (0); > } >=20 > int > diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c > index dbad1ae..b864c90 100644 > --- a/sys/kern/vfs_syscalls.c > +++ b/sys/kern/vfs_syscalls.c > @@ -4584,7 +4584,9 @@ int > sys_posix_fallocate(struct thread *td, struct posix_fallocate_args = *uap) > { >=20 > - return (kern_posix_fallocate(td, uap->fd, uap->offset, = uap->len)); > + td->td_retval[0] =3D kern_posix_fallocate(td, uap->fd, = uap->offset, > + uap->len); > + return (0); > } >=20 > /* -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 01:41:12 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org 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 D65FB9B4 for ; Fri, 24 Jan 2014 01:41:12 +0000 (UTC) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 62E0013B7 for ; Fri, 24 Jan 2014 01:41:08 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=date:from:to :cc:subject:message-id:mime-version:content-type; q=dns; s=sweb; b= szw+C7Gv7c006RPbqYdwi7xYmIaQ3f2ukXUPmfrFBnN2kH+ye8KTETnBAB2ABIlF KSMQofsAcrR/AaNC6mmSN2eDS6ONI57bZMEDCiU82LVZbtOxkEBVXGOd2CVaeCdk 9qS0Xt0K+ICBLRUtuDIddbR8Xu0T8Lya0Z9+PQDWxeI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=date:from :to:cc:subject:message-id:mime-version:content-type; s=sweb; bh= ZychxXsoIf6tvVpJXluuOZzU8CkTopcvtx+eiNdVE38=; b=otcn8rlWKF1S9fX2 Px2Ku1MIVCxCWIfbQfE471SCjjkNQyMORztmG6WDnKDgl8qxAhfUYXYItv6OcTXF I4MAxUrR9KWIoAopdHAAP2aRrS80LcScrEjDEDl7fYl/oO4irNYwpvcLPmy85pgO +pVax2756hVQmxIm4vyq7FkEmlY= Received: (qmail 53479 invoked from network); 23 Jan 2014 19:41:06 -0600 Received: from unknown (HELO admin.xzibition.com) (bryan@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 23 Jan 2014 19:41:06 -0600 Date: Thu, 23 Jan 2014 19:41:05 -0600 From: Bryan Drewery To: freebsd-standards@FreeBSD.org Subject: closedir(3) handling NULL Message-ID: <20140124014105.GC37334@admin.xzibition.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bjuZg6miEcdLYP6q" Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) Cc: bapt@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 01:41:13 -0000 --bjuZg6miEcdLYP6q Content-Type: multipart/mixed; boundary="7gGkHNMELEOhSGF6" Content-Disposition: inline --7gGkHNMELEOhSGF6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Please review. I would like to commit this. I found that Linux handles closedir(NULL) fine and returns EINVAL. POSIX [1] specifies that EBADF should be returned if "The dirp argument does not refer to an open directory stream" [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/closedir.html I've updated fdclosedir(3) as well to behave the same. I'll also update the manpage if there is no objection. Thanks, Bryan Drewery --7gGkHNMELEOhSGF6 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="closedir-NULL.diff" Content-Transfer-Encoding: quoted-printable Fix closedir(3) and fdclosedir(3) to return EBADF on NULL value. POSIX specifies that EBADF should be returned if "The dirp argument does not refer to an open directory stream" diff --git lib/libc/gen/closedir.c lib/libc/gen/closedir.c index 88ded37..d7a5bdb 100644 --- lib/libc/gen/closedir.c +++ lib/libc/gen/closedir.c @@ -53,6 +53,11 @@ fdclosedir(DIR *dirp) { int fd; =20 + if (dirp =3D=3D NULL) { + errno =3D EBADF; + return (-1); + } + if (__isthreaded) _pthread_mutex_lock(&dirp->dd_lock); fd =3D dirp->dd_fd; @@ -71,6 +76,10 @@ fdclosedir(DIR *dirp) int closedir(DIR *dirp) { + int fd; + + if ((fd =3D fdclosedir(dirp)) =3D=3D -1) + return (-1); =20 - return (_close(fdclosedir(dirp))); + return (_close(fd)); } --7gGkHNMELEOhSGF6-- --bjuZg6miEcdLYP6q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS4cSxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNkZFQkU5OTJGNTI4MERGNDgxMTM2MkE2 RTc4MkFDMDNDOUIwQ0Y5AAoJEG54KsA8mwz5tKUP+QEo5yVcaAynGvyVVJmEr0m2 IuXb4UaAOVnGKu3Ju85vegOZR/r6QIfObMtgykJspb/TbKqG0t2GXH81UYUnXCJl qsCH5Vm0LOowdPuv50DZRr0/Ewwn/jDR152xhQJ4qn2sna7EWXNm9vRObNUp8Qru FqBN6RSvmHvdxR9E7/GnN1cGsEDofJTJIGl23ejQu5+mQoXbFaudsGSLEmERBAb2 lygGZzJVKHZHnLLECmvnW8OYh/kOoZVuaC5rny2JjEMbFdy6uon3vUEJ7KRpWf6h yjgAJyZxpQrMl+/K7x4ZgIq7hI7FE8y6G5r9pyYgYI3dNqrtXsWpQmHFzmCYVzF2 7l/BPfw9a8uj4JJXEmkVsBLpjt7V/prL9HlHRWYK0LwcLpfv1YzYBt1JcVQy/63+ 8/r4ftSd/t38t6wIK1dTuWvjogANqagqA64PGO5lyCGJLe9w3HUnTWshDsg5iyu8 zq50+SDwjDor4cSVwJfIX1DXcRQwHmdF8SnChxfZLxseHUipRORPxW3vbg3wSqj9 z46EfCwJWEr6nO6FRYU5ChAFd6uHPdLfVOvlQT1xyV4SAibR/EMoX3KNCOW7gbsX ULCsVL8xrul2CweEpIM/vBbwHo+u/yhcF1PVyq6lnsmqqafq/V05GAkXE2Kl9jll XaYiMu7JxV24RYJNp7dW =ZQBm -----END PGP SIGNATURE----- --bjuZg6miEcdLYP6q-- From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 09:52:39 2014 Return-Path: Delivered-To: freebsd-standards@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FFD427B; Fri, 24 Jan 2014 09:52:39 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6272A195C; Fri, 24 Jan 2014 09:52:39 +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 s0O9qdii017717; Fri, 24 Jan 2014 09:52:39 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0O9qd5U017716; Fri, 24 Jan 2014 09:52:39 GMT (envelope-from linimon) Date: Fri, 24 Jan 2014 09:52:39 GMT Message-Id: <201401240952.s0O9qd5U017716@freefall.freebsd.org> To: dfilter@FreeBSD.ORG, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-standards@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: standards/186040: Re: standards/186028: commit references a PR X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 09:52:39 -0000 Old Synopsis: Re: standard/186028: commit references a PR New Synopsis: Re: standards/186028: commit references a PR State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Fri Jan 24 09:51:48 UTC 2014 State-Changed-Why: Misfiled followup to standards/186028; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-standards Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 24 09:51:48 UTC 2014 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=186040 From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 11:20:02 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 497FD7A6 for ; Fri, 24 Jan 2014 11:20:02 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A2EA123E for ; Fri, 24 Jan 2014 11:20:02 +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 s0OBK1v3036125 for ; Fri, 24 Jan 2014 11:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0OBK1gl036124; Fri, 24 Jan 2014 11:20:01 GMT (envelope-from gnats) Date: Fri, 24 Jan 2014 11:20:01 GMT Message-Id: <201401241120.s0OBK1gl036124@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org Cc: From: Bob Bishop Subject: Re: standards/186028: incorrect return values for posix_fallocate() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Bob Bishop List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 11:20:02 -0000 The following reply was made to PR standards/186028; it has been noted by GNATS. From: Bob Bishop To: bug-followup@FreeBSD.org Cc: Subject: Re: standards/186028: incorrect return values for posix_fallocate() Date: Fri, 24 Jan 2014 11:11:05 +0000 FWIW at least posix_madvise() and posix_fadvise() have the same problem = wrt man page, haven't checked the code. From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 13:24:39 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org 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 2CD47EB5; Fri, 24 Jan 2014 13:24:39 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E5BD21CA4; Fri, 24 Jan 2014 13:24:38 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 23CFDB8407; Fri, 24 Jan 2014 14:24:36 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 07E2028497; Fri, 24 Jan 2014 14:24:36 +0100 (CET) Date: Fri, 24 Jan 2014 14:24:35 +0100 From: Jilles Tjoelker To: Bryan Drewery Subject: Re: closedir(3) handling NULL Message-ID: <20140124132435.GA90996@stack.nl> References: <20140124014105.GC37334@admin.xzibition.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140124014105.GC37334@admin.xzibition.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 13:24:39 -0000 On Thu, Jan 23, 2014 at 07:41:05PM -0600, Bryan Drewery wrote: > I found that Linux handles closedir(NULL) fine and returns EINVAL. POSIX > [1] specifies that EBADF should be returned if "The dirp argument does > not refer to an open directory stream" > [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/closedir.html > I've updated fdclosedir(3) as well to behave the same. > I'll also update the manpage if there is no objection. If you do this, it is to improve compatibility with poorly written software and not for POSIX compliance. POSIX only permits passing null pointers where explicitly specified (e.g. time()); otherwise, passing a null pointer is undefined behaviour like passing any argument outside the required domain. On another note, I don't understand when the condition [EBADF] The dirp argument does not refer to an open directory stream. can actually apply. As far as I understand, only valid open directory streams (opendir() has been called and closedir() has not been called) may be passed to closedir() and other functions. If the pointer is not a null pointer, detecting whether it refers to a valid open directory stream is not possible using common methods (you could maintain a list of directory streams but doing that is against the spirit of C and I am quite sure that POSIX did not intend to require implementations to do that). In the current code in FreeBSD, [EBADF] may also happen if an application closes a directory stream's file descriptor from under it and no other file descriptor is opened in its place. In some cases like the file_name argument to realpath(), NULL is specified to cause an [EINVAL] return; I think we are stuck with that but should not add more such cases. Note that this [EINVAL] return also means that realpath(NULL, p) is valid to do and should not trigger undefined behaviour detectors. -- Jilles Tjoelker From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 16:55:21 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org 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 45529C6B for ; Fri, 24 Jan 2014 16:55:21 +0000 (UTC) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCF291269 for ; Fri, 24 Jan 2014 16:55:20 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sweb; b=dqBK6YFexjwPMUGXZsft1h5+FVpeabXuX 7h2bBbXI7QS5/rG1JqN1jyHilnwHi3fC3NSXBmKrMWXBRShkWKzcUDHxL78zyz1B kfy591SD4z8Ydi9+exHW9WJg3QynKciBilErn5kwbfMxNp1I/qUh9BMsAzom6B2r VZwZnXK3ec= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=sweb; bh=5BaqH8iyAMsOcAr8VupyZc3SHxebeI1YrWV74Ht BK1c=; b=omgIv12VMb0WNe+GRIeW+EdZb/n/prgUjnO6f3YvnSrldx/6OL2C6YX k0idMEcGZ/TZMHGiwP3+27+efQlBh3T247Q41WJhWDVJlaaaPZ6dL9OspT5HiLrL XkrqORe1qJnuuJEf4rWiGU85wQdVErmHbByUGYR7uyzj/NlqKM10= Received: (qmail 50074 invoked from network); 24 Jan 2014 10:55:13 -0600 Received: from unknown (HELO admin.xzibition.com) (bryan@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 24 Jan 2014 10:55:13 -0600 Date: Fri, 24 Jan 2014 10:55:09 -0600 From: Bryan Drewery To: Jilles Tjoelker Subject: Re: closedir(3) handling NULL Message-ID: <20140124165509.GA73838@admin.xzibition.com> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20140124132435.GA90996@stack.nl> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:55:21 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2014 at 02:24:35PM +0100, Jilles Tjoelker wrote: > On Thu, Jan 23, 2014 at 07:41:05PM -0600, Bryan Drewery wrote: > > I found that Linux handles closedir(NULL) fine and returns EINVAL. POSIX > > [1] specifies that EBADF should be returned if "The dirp argument does > > not refer to an open directory stream" >=20 > > [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/closedir.h= tml >=20 > > I've updated fdclosedir(3) as well to behave the same. >=20 > > I'll also update the manpage if there is no objection. >=20 > If you do this, it is to improve compatibility with poorly written > software and not for POSIX compliance. POSIX only permits passing null > pointers where explicitly specified (e.g. time()); otherwise, passing a > null pointer is undefined behaviour like passing any argument outside > the required domain. I do think that improving portability is important. Even against sloppy coding. Applications developed for Linux are fine passing NULL to closedir(= 3), which leads to a style of coding that does not reveal itself to be a problem on FreeBSD until an edge case comes up. This is the situation to led to me find this. A mountpoint disappeared and some code written for Linux, that ported to FreeBSD without changes, segfaulted in closedir(3). >=20 > On another note, I don't understand when the condition > [EBADF] The dirp argument does not refer to an open directory stream. > can actually apply. As far as I understand, only valid open directory > streams (opendir() has been called and closedir() has not been called) > may be passed to closedir() and other functions. If the pointer is not a > null pointer, detecting whether it refers to a valid open directory > stream is not possible using common methods (you could maintain a list > of directory streams but doing that is against the spirit of C and I am > quite sure that POSIX did not intend to require implementations to do > that). I was wondering that as well and whether EBADF really made sense, sicne it was not validating the pointer was from opendir(3). >=20 > In the current code in FreeBSD, [EBADF] may also happen if an > application closes a directory stream's file descriptor from under it > and no other file descriptor is opened in its place. >=20 > In some cases like the file_name argument to realpath(), NULL is > specified to cause an [EINVAL] return; I think we are stuck with that > but should not add more such cases. Note that this [EINVAL] return also > means that realpath(NULL, p) is valid to do and should not trigger > undefined behaviour detectors.. I'm not clear where you stand on this. Is EINVAL more proper or EBADF, or are you against the change all together? I find this sort of seat belt good for portability and of little harm. >=20 > --=20 > Jilles Tjoelker > _______________________________________________ > freebsd-standards@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-standards > To unsubscribe, send any mail to "freebsd-standards-unsubscribe@freebsd.o= rg" --FCuugMFkClbJLl1L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS4prsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNkZFQkU5OTJGNTI4MERGNDgxMTM2MkE2 RTc4MkFDMDNDOUIwQ0Y5AAoJEG54KsA8mwz5qZkP/2C2d6jzCNaTb38rozmrn3Dh 3amJWwgwokWv0oQOOiuW3mAPx74JkWrg9cwc3f9FASvSDl+ZP6y5jOc2ZcndTBuI wPWvdxcmK+kjUrXaG72mARjtQc5Ozf9eB6FP5wwP29i+uHGDqDscVcHnbR48oGNN f4EcoK+QHrgJj+d/LpEtwYgjUz5zQSWQWbTAFrJ0Ne/JCSKZ647Cv4PI7uSp45AE 9D2dzth/5m65IfROu9Ts6zf9rJi2/qeQN9KfVCIs18u4HCWclJmPGKKWkeQD/AwR RWTHZAMFsIQ0xOXrXwtWj9cjLA4cV+CkradUmJjrG4DU9ihBF8Y8F6B7kF4yPk63 r0B7W9lOOQ0mOVVBgj0Bb0Ny93Fyrd0gNZPnkjvOpGpOcOXe6zCiPdH/c2SIt7AS uhYmP1UCeELaSxqvMEV+mq3oDjKKlHb61CF3En9kNFd/JP7/MXHK/Ja5OMNVknNL Ljj/iRVcILwNc/jPdGf21d96ylFEEofme5Q7+iKu9Z2+AmgLeDQbSrnGWEi7NSC/ p79Vn/DQnI+VHPzEAvhzA3DOTd/UF3SD9FUC3X7EuMq1szQR4Vcs7IM6nkj7BoNu mJM+C5AF9zhBdUuaik9ZRP3U7ipMF3FaxX9NWBuOOX0EKcyBkSza24cahZHA5pTj WsiMyuBPf8v7F+Q1ybKC =vRNN -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 17:21:32 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org 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 94A8B662; Fri, 24 Jan 2014 17:21:32 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B181414BA; Fri, 24 Jan 2014 17:21:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s0OHLND5059900; Fri, 24 Jan 2014 19:21:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s0OHLND5059900 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s0OHLNP7059899; Fri, 24 Jan 2014 19:21:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Jan 2014 19:21:23 +0200 From: Konstantin Belousov To: Bryan Drewery Subject: Re: closedir(3) handling NULL Message-ID: <20140124172123.GK24664@kib.kiev.ua> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lildS9pRFgpM/xzO" Content-Disposition: inline In-Reply-To: <20140124165509.GA73838@admin.xzibition.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org, Jilles Tjoelker X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:21:32 -0000 --lildS9pRFgpM/xzO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2014 at 10:55:09AM -0600, Bryan Drewery wrote: > On Fri, Jan 24, 2014 at 02:24:35PM +0100, Jilles Tjoelker wrote: > > On Thu, Jan 23, 2014 at 07:41:05PM -0600, Bryan Drewery wrote: > > > I found that Linux handles closedir(NULL) fine and returns EINVAL. PO= SIX > > > [1] specifies that EBADF should be returned if "The dirp argument does > > > not refer to an open directory stream" > >=20 > > > [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/closedir= =2Ehtml > >=20 > > > I've updated fdclosedir(3) as well to behave the same. > >=20 > > > I'll also update the manpage if there is no objection. > >=20 > > If you do this, it is to improve compatibility with poorly written > > software and not for POSIX compliance. POSIX only permits passing null > > pointers where explicitly specified (e.g. time()); otherwise, passing a > > null pointer is undefined behaviour like passing any argument outside > > the required domain. >=20 > I do think that improving portability is important. Even against sloppy > coding. Applications developed for Linux are fine passing NULL to closedi= r(3), > which leads to a style of coding that does not reveal itself to be a > problem on FreeBSD until an edge case comes up. >=20 > This is the situation to led to me find this. A mountpoint disappeared > and some code written for Linux, that ported to FreeBSD without changes, > segfaulted in closedir(3). This is somewhat strange description of events, it definitely misses some intermediate steps. The mere fact of unmounting does not change anonymous memory content of some application. Even if the DIR * was assotiated with the directory descriptor belonging to the disappeared mount point, the DIR * and file descriptors are still valid, although not that functional. --lildS9pRFgpM/xzO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJS4qESAAoJEJDCuSvBvK1B/LUP/AgSoBHbnGylaKayoZG3LTLq 7T984ni+CrvrUQ+r/Mtfv69TdofmbhelWEDCocRqd75LULVn/M4ZOq8lt2RV3NP3 VN7Bd9Z3qegxL+tVH1tEjfwQ+RHbwVkbodOfcFzn8/0M5Qi7N0k6rdSTPGyeJmx0 uCKiEKE4hDXSRveb4Pghbh6PH4CXJWfYXI7/+sS4KQpr9TGUL4FkDvi2zsiAsqsH nd3UVUHVzMDShbjPw5XSw0mxdGTj9Pob5R4COjA7b1gsgTup3LvfddtJDwEWn2Z/ bW61/inV8ROe9hl2memrEK8cJnOqZIjefms8Asj+YymOzVoVWLJDW4Amfr2rnsiC fTSzJKoqqEzvWtpdiEfPmLehtuK9e1Sk72cr5iiw5PIJz8wJMHwkCXH7JW9bfZcP 5AKGDkdmimvV+eRoSBvgfJn16gpmjx5sldRE/f7JrUaytt2FlmwPUSIwhWInNZg/ wOBK+Zl5pkGp826b0XLXvQPgOnHOZzDSLXbCB2n4TEv3i9sUkcpfL1qCcvAhY4Zd gpVfU+vSe0ocvl6uAVm88Nnh3zbm/fXYbM4DV3wdM2JsyOcj6FAN2AjtfGkMRcuh WbNzQxjHZ5q14S0xt35Av6t/ACS2DV+2Dq/kvSBRrqMRDFsBsReFjStg1GpHsCYm PdL9cT+moz9JVNi65+DP =jNjw -----END PGP SIGNATURE----- --lildS9pRFgpM/xzO-- From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 17:49:43 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73DCE292 for ; Fri, 24 Jan 2014 17:49:43 +0000 (UTC) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 235CD1853 for ; Fri, 24 Jan 2014 17:49:43 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sweb; b=QtGaIQC7hi2Z9yPx14yuek+29BGaP3ER0 gERBABtktUArnAbIXiqFuQ/Q6gdctMt2irbwkceu8nPYTM6n8vJTnFXNIbf7xj1C 2BF+b9zWyWuoCM4eXnCOoNJ7XOIatSPChDc3ogvH+WjaXn5naf/UIQthQ8J0z5J/ K6XaJtbxRQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=sweb; bh=szqdAY/lfJwMd6pBhGz82JO771RpomiBKn1G5vC uopo=; b=UPyOhm7fUC//7YSKmaYGB0sgDDRL4PQ4vclQC3uq+K2N9Cv9jIFMrGx yFiaoy8gIEtSyGd7IqVIr85gHg3wrwtdkOve/W5iHeFJhsskmpkAOjY6o28Y8U4f Z23AkKJrakHcjgRkB0ifTd5yksucNBIuKcBq1TOQN2R+n6C78gOM= Received: (qmail 53688 invoked from network); 24 Jan 2014 11:49:40 -0600 Received: from unknown (HELO admin.xzibition.com) (bryan@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 24 Jan 2014 11:49:40 -0600 Date: Fri, 24 Jan 2014 11:49:39 -0600 From: Bryan Drewery To: Konstantin Belousov Subject: Re: closedir(3) handling NULL Message-ID: <20140124174938.GB73838@admin.xzibition.com> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> <20140124172123.GK24664@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: <20140124172123.GK24664@kib.kiev.ua> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org, Jilles Tjoelker X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:49:43 -0000 --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2014 at 07:21:23PM +0200, Konstantin Belousov wrote: > On Fri, Jan 24, 2014 at 10:55:09AM -0600, Bryan Drewery wrote: > > On Fri, Jan 24, 2014 at 02:24:35PM +0100, Jilles Tjoelker wrote: > > > On Thu, Jan 23, 2014 at 07:41:05PM -0600, Bryan Drewery wrote: > > > > I found that Linux handles closedir(NULL) fine and returns EINVAL. = POSIX > > > > [1] specifies that EBADF should be returned if "The dirp argument d= oes > > > > not refer to an open directory stream" > > >=20 > > > > [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/closed= ir.html > > >=20 > > > > I've updated fdclosedir(3) as well to behave the same. > > >=20 > > > > I'll also update the manpage if there is no objection. > > >=20 > > > If you do this, it is to improve compatibility with poorly written > > > software and not for POSIX compliance. POSIX only permits passing null > > > pointers where explicitly specified (e.g. time()); otherwise, passing= a > > > null pointer is undefined behaviour like passing any argument outside > > > the required domain. > >=20 > > I do think that improving portability is important. Even against sloppy > > coding. Applications developed for Linux are fine passing NULL to close= dir(3), > > which leads to a style of coding that does not reveal itself to be a > > problem on FreeBSD until an edge case comes up. > >=20 > > This is the situation to led to me find this. A mountpoint disappeared > > and some code written for Linux, that ported to FreeBSD without changes, > > segfaulted in closedir(3). > This is somewhat strange description of events, it definitely misses > some intermediate steps. The mere fact of unmounting does not change > anonymous memory content of some application. Even if the DIR * was > assotiated with the directory descriptor belonging to the disappeared > mount point, the DIR * and file descriptors are still valid, although > not that functional. The code constructed a path, called opendir(3), received NULL, skipped over code that uses the entry since it was NULL, then called closedir(3). Also, I don't find this very different than free(3) with a NULL. It's considered bad practice to check for NULL before calling it, why is closedir(3) any different? Regards, Bryan Drewery --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS4qeyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNkZFQkU5OTJGNTI4MERGNDgxMTM2MkE2 RTc4MkFDMDNDOUIwQ0Y5AAoJEG54KsA8mwz5pnEQAJnXxJWcElWv/ZRvwPyldug2 PDVrabYk6w5aaFPkINHm8GrNveQJMa7w6zvZGNpMpGhJgvNwSPjNxHVckrv6fN8M duKHGMfgun9VuoSYwzxX9fBIu0UNDywFm7BIbiRnwFotRY6BxE35K9/8EW29bU3Q V6Zy/LQv4uVFpkMafFX0OAnPS7TRRcGRNRoHlJPfRXu8Qd7IjcE2uEqyOmQ0KPlA BVL936xfAFuNfQJR4vdSsoOyRpSyLC1Cf8ewtlJHJkgnppX4IB/M1x6wd4mjHJvL 7sMBNmdEyu/Wjdr8m8+aX4WQdW756ZR2+MAKJWlUGvPqprDKnDg1cM5Tuh5iXLjX ilZ8RLLrYt5BJU+0e+LUCDGEoiNh7lYkC5Gu1d2d7MF/axqMHR4OYFfbBrMq4pzj SEa5y4QNzxEoIth9yRCxB321XQZ+9LkiYM90FS+Frc+GH+Jx57hVbB4FWEDNkxxJ YqKr7Ka1Ij+DDHJmeAiLHSxXRPQ4RCnjR+llI8zKr5d8wmed/h+ADdDqv3zmHXk/ oMOEiG9F/89472r0jG27rOM9IXcoxNapW/H8OMoH2NsNNuoC4hnZK6YHATuXeCGx XluC4L7BRllInPL/iI0IFy0i7peTjioNyocQ+Bh6o0fPTV82DKgGpjEaJKi99tJF aOP2s6dN2AJVKV+rnfZC =xlaf -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 18:06:41 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90D26828; Fri, 24 Jan 2014 18:06:41 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB1B419CC; Fri, 24 Jan 2014 18:06:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s0OI6Z2k069531; Fri, 24 Jan 2014 20:06:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s0OI6Z2k069531 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s0OI6ZoA069530; Fri, 24 Jan 2014 20:06:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Jan 2014 20:06:35 +0200 From: Konstantin Belousov To: Bryan Drewery Subject: Re: closedir(3) handling NULL Message-ID: <20140124180635.GN24664@kib.kiev.ua> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> <20140124172123.GK24664@kib.kiev.ua> <20140124174938.GB73838@admin.xzibition.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YuJye9aIuN0w6xGV" Content-Disposition: inline In-Reply-To: <20140124174938.GB73838@admin.xzibition.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org, Jilles Tjoelker X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:06:41 -0000 --YuJye9aIuN0w6xGV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2014 at 11:49:39AM -0600, Bryan Drewery wrote: > On Fri, Jan 24, 2014 at 07:21:23PM +0200, Konstantin Belousov wrote: > > On Fri, Jan 24, 2014 at 10:55:09AM -0600, Bryan Drewery wrote: > > > On Fri, Jan 24, 2014 at 02:24:35PM +0100, Jilles Tjoelker wrote: > > > > On Thu, Jan 23, 2014 at 07:41:05PM -0600, Bryan Drewery wrote: > > > > > I found that Linux handles closedir(NULL) fine and returns EINVAL= =2E POSIX > > > > > [1] specifies that EBADF should be returned if "The dirp argument= does > > > > > not refer to an open directory stream" > > > >=20 > > > > > [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/clos= edir.html > > > >=20 > > > > > I've updated fdclosedir(3) as well to behave the same. > > > >=20 > > > > > I'll also update the manpage if there is no objection. > > > >=20 > > > > If you do this, it is to improve compatibility with poorly written > > > > software and not for POSIX compliance. POSIX only permits passing n= ull > > > > pointers where explicitly specified (e.g. time()); otherwise, passi= ng a > > > > null pointer is undefined behaviour like passing any argument outsi= de > > > > the required domain. > > >=20 > > > I do think that improving portability is important. Even against slop= py > > > coding. Applications developed for Linux are fine passing NULL to clo= sedir(3), > > > which leads to a style of coding that does not reveal itself to be a > > > problem on FreeBSD until an edge case comes up. > > >=20 > > > This is the situation to led to me find this. A mountpoint disappeared > > > and some code written for Linux, that ported to FreeBSD without chang= es, > > > segfaulted in closedir(3). > > This is somewhat strange description of events, it definitely misses > > some intermediate steps. The mere fact of unmounting does not change > > anonymous memory content of some application. Even if the DIR * was > > assotiated with the directory descriptor belonging to the disappeared > > mount point, the DIR * and file descriptors are still valid, although > > not that functional. >=20 > The code constructed a path, called opendir(3), received NULL, skipped > over code that uses the entry since it was NULL, then called > closedir(3). >=20 > Also, I don't find this very different than free(3) with a NULL. It's > considered bad practice to check for NULL before calling it, why is > closedir(3) any different? Ok, so it does not have much to do with unmount, it is just an open of nonexistent path. I do not have an answer to the question about free(3), except that free(NULL) behaviour is required by ANSI C, while closedir(NULL) is not, by posix. --YuJye9aIuN0w6xGV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJS4quqAAoJEJDCuSvBvK1BOxcP/0HhDJ+9Ao2cRO+c74eDpqKC ZH2lbY439MnNc321rZL5wgKQoFFWJ6Wsr9iTuSnN5Mz++HHcz1gkIJ4b5EeZ+CXI JS+VsM2nRSZHEFTrY6Lf6XX8TosBv4eFEyTHQTiIll6oAta4sjA6DieOjwNXmlh/ ggTdmpymZxDofHAMWR+bOYq0yUTJ/kdAVu5OT6iKlgenEwaNY2wweTZdjq/a/cGH 6YS8o48MH14ohvXaw9icdlqaiqvswgvJxT+SrQfdxSCPSbP+cdSR3hGnfoGLICBU At/B/XlJT9HdLz81q9t/W1ULnof8YPP5NOU9MNBf2tazEwiOrAIIJ54WPQdNJnF4 DxbwHFyXGIV0zP8M7cdA42ZJw0rIIlu7ua53lBwjCPhzIBLYexVWrf5qx/eiJ9cy 4UbKlUFwQB+4wbjizX6lTElUka0APAMaIc5zS1iNUBOsDvsLCf8UubWBjPgHvGBH bE3zDLX5K4InyEVN64t/oLiyyddyWNdHPPZm5lFAERY7jRFCL5jGTd+Z8jAAVwGh E+JQ5qFF7i6fYWjalB7qFZt+0ZiBMnxRarqgtC7aMpyBJqHukG3asZs7OeypeBcE ZIs30y6O0ps3xdXRDY4SribKNX05HklzOpGHx1P4qr1xuJpiDDd8/S8Wd9hXgMRW FCjLdw5oFm17AbcqI6d+ =ZTYs -----END PGP SIGNATURE----- --YuJye9aIuN0w6xGV-- From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 18:08:57 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85146874 for ; Fri, 24 Jan 2014 18:08:57 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 528DB19DD for ; Fri, 24 Jan 2014 18:08:57 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0OI8t8l007792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Fri, 24 Jan 2014 13:08:55 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0OI8t2G007789; Fri, 24 Jan 2014 13:08:55 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21218.44087.838181.110669@khavrinen.csail.mit.edu> Date: Fri, 24 Jan 2014 13:08:55 -0500 From: Garrett Wollman To: Bryan Drewery Subject: Re: closedir(3) handling NULL In-Reply-To: <20140124165509.GA73838@admin.xzibition.com> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Fri, 24 Jan 2014 13:08:56 -0500 (EST) Cc: freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:08:57 -0000 < said: > I'm not clear where you stand on this. Is EINVAL more proper or EBADF, > or are you against the change all together? If you pass a null pointer to a function that does not expect one, the result is undefined. If the process is not terminated, its state (including errno and any register or memory contents) may be set to any value whatsoever. If it were me, and I for some reason wanted to check this corner case explicitly, I'd use [EFAULT]. -GAWollman From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 18:12:54 2014 Return-Path: Delivered-To: standards@freebsd.org 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 79E4EAD9; Fri, 24 Jan 2014 18:12:54 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7728D1A70; Fri, 24 Jan 2014 18:12:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s0OICk9D070612; Fri, 24 Jan 2014 20:12:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s0OICk9D070612 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s0OICk5g070611; Fri, 24 Jan 2014 20:12:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Jan 2014 20:12:46 +0200 From: Konstantin Belousov To: Bob Bishop Subject: Re: standards/186028: incorrect return values for posix_fallocate() Message-ID: <20140124181246.GO24664@kib.kiev.ua> References: <201401230858.s0N8wwQB039907@oldred.freebsd.org> <20140123094017.GH24664@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gh4H09KImyIEQ1se" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Gennady Proskurin , mdf@freebsd.org, standards@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:12:54 -0000 --gh4H09KImyIEQ1se Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 23, 2014 at 09:20:11PM +0000, Bob Bishop wrote: > Hi, >=20 > On 23 Jan 2014, at 09:40, Konstantin Belousov wrote: >=20 > > On Thu, Jan 23, 2014 at 08:58:58AM +0000, Gennady Proskurin wrote: > >>=20 > >>> Number: 186028 > >>> Category: standards > >>> Synopsis: incorrect return values for posix_fallocate() > >>> Confidential: no > >>> Severity: non-critical > >>> Priority: low > >>> Responsible: freebsd-standards > >>> State: open > >>> Quarter: =20 > >>> Keywords: =20 > >>> Date-Required: > >>> Class: sw-bug > >>> Submitter-Id: current-users > >>> Arrival-Date: Thu Jan 23 09:00:00 UTC 2014 > >>> Closed-Date: > >>> Last-Modified: > >>> Originator: Gennady Proskurin > >>> Release: FreeBSD 11.0-CURRENT > >>> Organization: > >>> Environment: > >> FreeBSD gpr.nnz-home.ru 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r260472+7= 43aa78(svn_head): Fri Jan 10 05:28:05 MSK 2014 gpr@gpr.nnz-home.ru:/usr= /obj/usr/src/freebsd-head/sys/GPR amd64 > >>> Description: > >> In case of error, posix_fallocate() should return error code itself, b= ut in FreeBSD it returns -1 and sets errno. >=20 > FWIW at least posix_madvise() and posix_fadvise() have the same problem. Indeed, I suppose the following should also fix two syscalls noted. I hope that some doc committer would do the pass over man pages following Bruce' suggestions. diff --git a/lib/libc/gen/pmadvise.c b/lib/libc/gen/pmadvise.c index 60cef63..68b1181 100644 --- a/lib/libc/gen/pmadvise.c +++ b/lib/libc/gen/pmadvise.c @@ -12,5 +12,14 @@ __FBSDID("$FreeBSD$"); int posix_madvise(void *address, size_t size, int how) { - return madvise(address, size, how); + int ret, saved_errno; + + saved_errno =3D errno; + if (madvise(address, size, how) =3D=3D -1) { + ret =3D errno; + errno =3D saved_errno; + } else { + ret =3D 0; + } + return (ret); } diff --git a/lib/libc/sys/madvise.2 b/lib/libc/sys/madvise.2 index b5ea6b2..755ecc2 100644 --- a/lib/libc/sys/madvise.2 +++ b/lib/libc/sys/madvise.2 @@ -50,7 +50,10 @@ allows a process that has knowledge of its memory behavi= or to describe it to the system. The .Fn posix_madvise -interface is identical and is provided for standards conformance. +interface is identical, except it returns an error number on error and does +not modify +.Va errno , +and is provided for standards conformance. .Pp The known behaviors are: .Bl -tag -width MADV_SEQUENTIAL diff --git a/lib/libc/sys/posix_fadvise.2 b/lib/libc/sys/posix_fadvise.2 index 7a9a648..96c99d2 100644 --- a/lib/libc/sys/posix_fadvise.2 +++ b/lib/libc/sys/posix_fadvise.2 @@ -93,7 +93,7 @@ Future access to this data may require a read operation. .Sh ERRORS The .Fn posix_fadvise -system call will fail if: +system call returns zero on success, and an error on failure: .Bl -tag -width Er .It Bq Er EBADF The diff --git a/lib/libc/sys/posix_fallocate.2 b/lib/libc/sys/posix_fallocate.2 index 1460764..7501777 100644 --- a/lib/libc/sys/posix_fallocate.2 +++ b/lib/libc/sys/posix_fallocate.2 @@ -83,9 +83,8 @@ that reduces the file size to a size smaller than If successful, .Fn posix_fallocate returns zero. -It returns error number on failure, without setting -.Va errno -variable. +It returns an error on failure, without setting +.Va errno . .Sh ERRORS Possible failure conditions: .Bl -tag -width Er diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index e4ffbe4..c7b677f 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -3005,8 +3005,10 @@ freebsd32_posix_fadvise(struct thread *td, struct freebsd32_posix_fadvise_args *uap) { =20 - return (kern_posix_fadvise(td, uap->fd, PAIR32TO64(off_t, uap->offset), - PAIR32TO64(off_t, uap->len), uap->advice)); + td->td_retval[0] =3D kern_posix_fadvise(td, uap->fd, + PAIR32TO64(off_t, uap->offset), PAIR32TO64(off_t, uap->len), + uap->advice); + return (0); } =20 int diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index b864c90..4be9738 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -4725,6 +4725,7 @@ int sys_posix_fadvise(struct thread *td, struct posix_fadvise_args *uap) { =20 - return (kern_posix_fadvise(td, uap->fd, uap->offset, uap->len, - uap->advice)); + td->td_retval[0] =3D kern_posix_fadvise(td, uap->fd, uap->offset, + uap->len, uap->advice); + return (0); } --gh4H09KImyIEQ1se Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJS4q0dAAoJEJDCuSvBvK1BKz8P/AgpeU9JoVbVt3xLHOwOgu0Z 2kXxFPCViJR/R0ZOsaZSrmKRPbFTnkkyPLCDuRZ6yExznRxwUlLc0nMauEa/+wmx 0eJUeIuoNAY6JgayvqJyaH9RK+K9UEKwQInOfUcFKPwDTH4qq3eY//EoJfvW8Ds2 fm32RRXWMoMRoBHxeYp15am0zmMJ3LluhWZ9dEp53s1qYNkZkvJDoA1ikNK2Ndnp lX17+UFq8LpOZB0dTHDhM2whsGuKu0NjnF2cLs/W26xq1Spyf+f4D2tg3hiFeNuB hc7h1W+Ygm9LvtqUY9NTxYQrG9UtF0xUMd0jX1N57KAO51a5d9Ph+r+YVM5zBJ8i 1KYz3/1/gdzOzDzpRoeQ79uKg5MQpVdJfYuSj5qgOzC2N6UUsC7Q1XIM9ygmJLSs aR03lkwjMy5RJTTT0hWB12NVfoF66OdrXve0p7WkYTAanSd1AQxoI4S4XG4POKle AIlQ27jAvWK0G7dl5ZoOeYL3FzWZTLrZ4twTddHPiN3shwH+//ZoNdwQoxYdnzAJ 9zI0LTlAbQ5p/GzKC5+IfUiQXwfj+odaZh39vlpddnkNEz9uPrKqs1MRbVA0LEmz ifAPFdg9RhxTokeo1B5Pq/TKQcosGXKhmOsEIV3ACBh9digQRnjJ3HMtMBwsAR+o ka6fY74p6Q0YrTv/xlMw =EtIo -----END PGP SIGNATURE----- --gh4H09KImyIEQ1se-- From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 19:00:27 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CFACB9A; Fri, 24 Jan 2014 19:00:27 +0000 (UTC) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id CB74A1F3D; Fri, 24 Jan 2014 19:00:26 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id C300A780385; Sat, 25 Jan 2014 06:00:15 +1100 (EST) Date: Sat, 25 Jan 2014 06:00:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bryan Drewery Subject: Re: closedir(3) handling NULL In-Reply-To: <20140124165509.GA73838@admin.xzibition.com> Message-ID: <20140125041504.Y986@besplex.bde.org> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=HZAtEE08 c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=FLjmdRbynEcA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=s-lAilbsuXwA:10 a=uZvujYp8AAAA:8 a=7sGoTPPwGPE-XhCQSWoA:9 a=CjuIK1q_8ugA:10 a=MKQCoWhop30A:10 Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org, Jilles Tjoelker X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:00:27 -0000 On Fri, 24 Jan 2014, Bryan Drewery wrote: > On Fri, Jan 24, 2014 at 02:24:35PM +0100, Jilles Tjoelker wrote: >> On Thu, Jan 23, 2014 at 07:41:05PM -0600, Bryan Drewery wrote: >>> I found that Linux handles closedir(NULL) fine and returns EINVAL. POSIX >>> [1] specifies that EBADF should be returned if "The dirp argument does >>> not refer to an open directory stream" >> >>> [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/closedir.html Bug in POSIX. It actually doesn't say this, but says in a confusing way that "among the undefined behaviours that occurs if the dirp argument does not refer to an open directory stream, the implementation is permitted but not required to return -1 and set errno to EBADF". Since the undefined behaviour includes doing this, the part about returning EBADF says nothing at all. Similarly for returning NULL. >>> I've updated fdclosedir(3) as well to behave the same. >> >>> I'll also update the manpage if there is no objection. >> >> If you do this, it is to improve compatibility with poorly written >> software and not for POSIX compliance. POSIX only permits passing null >> pointers where explicitly specified (e.g. time()); otherwise, passing a >> null pointer is undefined behaviour like passing any argument outside >> the required domain. fclose() is a better example than time(). POSIX follows C for fclose() and thus has fewer design and wording bugs for fclose() than for closedir(). Its actual wording for closedir() is (from the 2001 draft7; nothing has changed): % 7035 NAME % 7036 closedir - close a directory stream % % 7037 SYNOPSIS % 7038 #include % 7039 int closedir(DIR *dirp); % % 7040 DESCRIPTION % 7041 The closedir( ) function shall close the directory stream referred to by the argument dirp. Upon Already the behaviour is undefined, just like for fclose(), if the arg is not a stream. % 7042 return, the value of dirp may no longer point to an accessible object of the type DIR. If a file Note that in POSIX, "may" is a (poorly chosen) technical term. It means that the implementation is permitted to, at its option, implement the indicated behaviour, but portable applications can not depend on this behaviour. % 7043 descriptor is used to implement type DIR, that file descriptor shall be closed. % % 7044 RETURN VALUE % 7045 Upon successful completion, closedir( ) shall return 0; otherwise, -1 shall be returned and errno % 7046 set to indicate the error. % % 7047 ERRORS % 7048 The closedir( ) function may fail if: % 7049 [EBADF] The dirp argument does not refer to an open directory stream. This "may" is even more confusing. Since a previous closedir() _may_ have turned dirp into garbage, EBADF need not happen naturally due to close() on an already-closed descriptor pointed to by a closed dirp. The implementation is permitted to fake this, but the behaviour is already undefined in this case so no permission is needed. I don't see how EBADF can ever happen naturally if dirp is a directory stream -- directory streams must be open, so they cannot have a closed file descriptor in them and closing of an open file descriptor cannoth produce EBADF. > I do think that improving portability is important. Even against sloppy > coding. Applications developed for Linux are fine passing NULL to closedir(3), > which leads to a style of coding that does not reveal itself to be a > problem on FreeBSD until an edge case comes up. This unimproves portability. FreeBSD intentionally does the opposite for fclose(): from fclose(3): @ NOTES @ The fclose() function does not handle NULL arguments; they will result in @ a segmentation violation. This is intentional - it makes it easier to @ make sure programs written under FreeBSD are bug free. This behaviour is @ an implementation detail, and programs should not rely upon it. It would be good to do the same thing for garbage stream pointers. I once implemented the opposite of this for stdio (all entry points except macros IIRC). Garbage stream pointers can be detected by keeping a list of valid ones and checking that the supposed stream arg is in the list. Use a hash to search efficiently. The implementation used a hash value pointed to by the stream arg (fp->_fp_hash). This was on hardware that couldn't trap when following a garbage pointer. If the hardware traps, then this would require either a trap handler or caclulation of a hash value from the value of fp. After detecting a garbage pointer, I did the wrong thing of making the stdio functions fail instead of SIGSEGVing. Streams that are valid but wrong cannot be detected. The most common error is probably a closed stream. fp->_fp_hash and even fp->_fp_fileno could be kept valid for closed streams using type-stable memory. > This is the situation to led to me find this. A mountpoint disappeared > and some code written for Linux, that ported to FreeBSD without changes, > segfaulted in closedir(3). FreeBSD was perfect :-). >> On another note, I don't understand when the condition >> [EBADF] The dirp argument does not refer to an open directory stream. >> can actually apply. As far as I understand, only valid open directory >> streams (opendir() has been called and closedir() has not been called) >> may be passed to closedir() and other functions. Yes, I couldn't see how this could happen either. Maybe some choices in the "may"s makes it possible. >> If the pointer is not a >> null pointer, detecting whether it refers to a valid open directory >> stream is not possible using common methods (you could maintain a list >> of directory streams but doing that is against the spirit of C and I am >> quite sure that POSIX did not intend to require implementations to do >> that). When I did this, it was for a 16-bit system. stdio was about 1/10 as large as in FreeBSD and libc was about 1/100 as large. So space considerations don't prevent doing this. You can also do a simple check using magic numbers that detects most cases. > I was wondering that as well and whether EBADF really made sense, sicne > it was not validating the pointer was from opendir(3). > >> In the current code in FreeBSD, [EBADF] may also happen if an >> application closes a directory stream's file descriptor from under it >> and no other file descriptor is opened in its place. Ah, that is a reason. revoke() by the sysadmin is an even more legitimate reason (maybe the fd is still valid them, but it is worse than useless). >> In some cases like the file_name argument to realpath(), NULL is >> specified to cause an [EINVAL] return; I think we are stuck with that >> but should not add more such cases. Note that this [EINVAL] return also >> means that realpath(NULL, p) is valid to do and should not trigger >> undefined behaviour detectors.. It's OK to have an extension to make null pointers give defined behaviour. Requiring an error for null pointers pevents such extensions. I find it hard to remember that fclose(NULL) isn't already an extension (giving fcloseall()). > I'm not clear where you stand on this. Is EINVAL more proper or EBADF, > or are you against the change all together? > > I find this sort of seat belt good for portability and of little harm. % diff --git lib/libc/gen/closedir.c lib/libc/gen/closedir.c % index 88ded37..d7a5bdb 100644 % --- lib/libc/gen/closedir.c % +++ lib/libc/gen/closedir.c % @@ -53,6 +53,11 @@ fdclosedir(DIR *dirp) % { % int fd; % % + if (dirp == NULL) { % + errno = EBADF; % + return (-1); % + } % + Style bug (extra blank line). % if (__isthreaded) % _pthread_mutex_lock(&dirp->dd_lock); Example of normal style (no extra blank line after an if statement). Extra blank lines are especially not needed after return statements since return statements obviously don't fall through. % fd = dirp->dd_fd; % @@ -71,6 +76,10 @@ fdclosedir(DIR *dirp) % int % closedir(DIR *dirp) % { % + int fd; % + % + if ((fd = fdclosedir(dirp)) == -1) % + return (-1); % Style bug (extra blank line). There is no man page for fdclosedir(3). It is in directory(3), but someone forgot to add fdclosedir.3 to MLINKS. fdopendir.3 is unsorted in MLINKS instead of missing. % - return (_close(fdclosedir(dirp))); % + return (_close(fd)); % } This is necessary iff you allow fdclosedir() to return on null pointers. Among the dirent functions, only closedir() and fdclosedir() "work" on null pointers, and this is not documented. More POSIX wording: % 186 may % 187 Describes a feature or behavior that is optional for an implementation that conforms to % 188 IEEE Std 1003.1-200x. An application should not rely on the existence of the feature or % 189 behavior. An application that relies on such a feature or behavior cannot be assured to be % 190 portable across conforming implementations. % 191 To avoid ambiguity, the opposite of may is expressed as need not, instead of may not. In non-technical English, "may" means either permission or happenstance. It is ambigous so it should never be used. It is often used. It is most often used for happenstance when "might" should be used. POSIX uses it for a special type of permission. I don't know if POSIX requires the implementation to document its choice of option. FreeBSD's closedir(3) documents that the dirp is a pointer that becomes free on both successful completion (it uses unnecessarily complex sentences which make it less than clear that freeing occurs in the failure case). % 10718 The fclose( ) function shall cause the stream pointed to by stream to be flushed and the associated % 10719 file to be closed. Any unwritten buffered data for the stream shall be written to the file; any % % 10732 ERRORS % 10733 The fclose( ) function shall fail if: % ... % 10736 CX [EBADF] The file descriptor underlying stream is not valid. I don't know how the fd can be invalid for a (necessarily valid) stream. Maybe because the fd for a stdio stream is not private, and POSIX actually allows closing it directly. At least this says "shall fail" instead of "may fail". I think the "may fail" for closedir() is just buggy wording. The "may" is for the implementation not being required to use fd's at all. But when it uses them, errors from them should be "shall fail" like they are for fclose(). Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 19:26:42 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA1EE3A9 for ; Fri, 24 Jan 2014 19:26:42 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B771F10EE for ; Fri, 24 Jan 2014 19:26:42 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0OJQfVE008327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Fri, 24 Jan 2014 14:26:41 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0OJQeiW008324; Fri, 24 Jan 2014 14:26:40 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21218.48752.949231.855028@khavrinen.csail.mit.edu> Date: Fri, 24 Jan 2014 14:26:40 -0500 From: Garrett Wollman To: Bruce Evans Subject: Re: closedir(3) handling NULL In-Reply-To: <20140125041504.Y986@besplex.bde.org> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> <20140125041504.Y986@besplex.bde.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Fri, 24 Jan 2014 14:26:41 -0500 (EST) Cc: freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:26:43 -0000 < said: > I don't know how the fd can be invalid for a (necessarily valid) stream. > Maybe because the fd for a stdio stream is not private, and POSIX actually > allows closing it directly. At least this says "shall fail" instead of > "may fail". I think the "may fail" for closedir() is just buggy wording. > The "may" is for the implementation not being required to use fd's at all. > But when it uses them, errors from them should be "shall fail" like they > are for fclose(). "may fail" has a very specific meaning in the "ERRORS" section: if the implementation detects the condition described, it must use the specified error number. -GAWollman From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 19:46:28 2014 Return-Path: Delivered-To: standards@freebsd.org 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 AE63176E; Fri, 24 Jan 2014 19:46:28 +0000 (UTC) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1E11239; Fri, 24 Jan 2014 19:46:27 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id B0C9B10427CC; Sat, 25 Jan 2014 06:46:17 +1100 (EST) Date: Sat, 25 Jan 2014 06:46:16 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: standards/186028: incorrect return values for posix_fallocate() In-Reply-To: <20140124181246.GO24664@kib.kiev.ua> Message-ID: <20140125062048.R1518@besplex.bde.org> References: <201401230858.s0N8wwQB039907@oldred.freebsd.org> <20140123094017.GH24664@kib.kiev.ua> <20140124181246.GO24664@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=1FcmvNfKhqQA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=3BHb2PuD7wgA:10 a=mZzAHOREtoPiIx4mOO4A:9 a=FL8u1aDBdp1bwC8t:21 a=Pk_QPew9c39CfSb_:21 a=CjuIK1q_8ugA:10 Cc: Gennady Proskurin , mdf@freebsd.org, standards@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:46:28 -0000 On Fri, 24 Jan 2014, Konstantin Belousov wrote: > On Thu, Jan 23, 2014 at 09:20:11PM +0000, Bob Bishop wrote: >> FWIW at least posix_madvise() and posix_fadvise() have the same problem. > > Indeed, I suppose the following should also fix two syscalls noted. > I hope that some doc committer would do the pass over man pages > following Bruce' suggestions. > > diff --git a/lib/libc/gen/pmadvise.c b/lib/libc/gen/pmadvise.c > index 60cef63..68b1181 100644 > --- a/lib/libc/gen/pmadvise.c > +++ b/lib/libc/gen/pmadvise.c > @@ -12,5 +12,14 @@ __FBSDID("$FreeBSD$"); > int > posix_madvise(void *address, size_t size, int how) > { > - return madvise(address, size, how); > + int ret, saved_errno; > + > + saved_errno = errno; > + if (madvise(address, size, how) == -1) { > + ret = errno; > + errno = saved_errno; > + } else { > + ret = 0; > + } > + return (ret); > } I think it is better to not preserve errno, but to intentionally clobber it to the same value as madvise() does. Its value is unspecified, and it is better to set it to new garbage than old garbage in case the application doesn't understand POSIX's suprising error handling. This follows from C's specification of errno and POSIX's not saying anything about errnor for posix_madvise(). From a C99 draft: [#3] The value of errno is zero at program startup, but is never set to zero by any library function.159) The value of errno may be set to nonzero by a library function call whether or not there is an error, provided the use of errno is not documented in the description of the function in this International Standard. So any library function can set errno to any nonzero value other than 0, unless it is specifically documented to not do so. stdio (__smakebuf()) setting errno to ENOTTY on success in most cases (by calling isatty() on a non-terminal) a classic example, and posix_madvise() should be no different, with more reason than stdio. In the above, you preserve errno on failure but don't explicitly preserve it on sucess. madvise() doesn't clobber it on success, but this is an implementation detail. For most functions, errno becomes garbage on success. In POSIX, isatty() is permitted but not required to set errno on success. stdio is not special except that it is required to set errno to a specific value on certain errors and required to set errno "to indicate the error" for all errors. (I only checked fopen() here. I forgot that ENOTTY tends to occur later in FreeBSD stdio due to delayed buffer allocation. The buffer allocation optimizations are mostly pessimizations for both space and time due to bloat in libc. Static allocation of huge buffers would lose less.) > diff --git a/lib/libc/sys/madvise.2 b/lib/libc/sys/madvise.2 > index b5ea6b2..755ecc2 100644 > --- a/lib/libc/sys/madvise.2 > +++ b/lib/libc/sys/madvise.2 > @@ -50,7 +50,10 @@ allows a process that has knowledge of its memory behavior > to describe it to the system. > The > .Fn posix_madvise > -interface is identical and is provided for standards conformance. > +interface is identical, except it returns an error number on error and does > +not modify > +.Va errno , > +and is provided for standards conformance. > .Pp > The known behaviors are: > .Bl -tag -width MADV_SEQUENTIAL The man pages emphasize not setting errno too much. This matches your implementation (assuming the undocmented behaviour that madvise() doesn't modify errno on success), but applications shouldn't depend on this. Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 20:28:14 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2486735 for ; Fri, 24 Jan 2014 20:28:14 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96CDC15BB for ; Fri, 24 Jan 2014 20:28:14 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0OKSCM4009010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Fri, 24 Jan 2014 15:28:13 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0OKSCkC009007; Fri, 24 Jan 2014 15:28:12 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21218.52444.765847.64846@khavrinen.csail.mit.edu> Date: Fri, 24 Jan 2014 15:28:12 -0500 From: Garrett Wollman To: Bruce Evans Subject: Re: closedir(3) handling NULL In-Reply-To: <20140125065355.P1644@besplex.bde.org> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> <20140125041504.Y986@besplex.bde.org> <21218.48752.949231.855028@khavrinen.csail.mit.edu> <20140125065355.P1644@besplex.bde.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Fri, 24 Jan 2014 15:28:13 -0500 (EST) Cc: freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:28:14 -0000 < said: > On Fri, 24 Jan 2014, Garrett Wollman wrote: >> "may fail" has a very specific meaning in the "ERRORS" section: if the >> implementation detects the condition described, it must use the >> specified error number. > That doesn't quite do it. Detection of the error for closing a closed fd > is still not required, unlike for fclose(). That is correct. If the implementation detects this condition and returns an error, it must indicate [EBADF]. But it need not detect that condition, even if that will prevent it from performing the function, and in that case, the function's behavior is unspecified. Since there are no "shall"s involved, no conformance distinction can be made between two implementations, one of which detects an invalid stream and indicates [EBADF], and the other of which does not detect an invalid stream but turns your computer into a frog. -GAWollman From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 20:28:24 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F049758 for ; Fri, 24 Jan 2014 20:28:24 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE2015BC for ; Fri, 24 Jan 2014 20:28:23 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id D9AC442456F; Sat, 25 Jan 2014 07:08:51 +1100 (EST) Date: Sat, 25 Jan 2014 07:08:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Garrett Wollman Subject: Re: closedir(3) handling NULL In-Reply-To: <21218.48752.949231.855028@khavrinen.csail.mit.edu> Message-ID: <20140125065355.P1644@besplex.bde.org> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> <20140125041504.Y986@besplex.bde.org> <21218.48752.949231.855028@khavrinen.csail.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=FLjmdRbynEcA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=s-lAilbsuXwA:10 a=ADeeF_SfVXO_LmrnBxMA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:28:24 -0000 On Fri, 24 Jan 2014, Garrett Wollman wrote: > < said: > >> I don't know how the fd can be invalid for a (necessarily valid) stream. >> Maybe because the fd for a stdio stream is not private, and POSIX actually >> allows closing it directly. At least this says "shall fail" instead of >> "may fail". I think the "may fail" for closedir() is just buggy wording. >> The "may" is for the implementation not being required to use fd's at all. >> But when it uses them, errors from them should be "shall fail" like they >> are for fclose(). > > "may fail" has a very specific meaning in the "ERRORS" section: if the > implementation detects the condition described, it must use the > specified error number. That doesn't quite do it. Detection of the error for closing a closed fd is still not required, unlike for fclose(). I could only find the above implied indirectly, and not completely. % 435 RETURN VALUE % 436 This section indicates the possible return values, if any. % 437 If the implementation can detect errors, ``successful completion'' means that no error % 438 has been detected during execution of the function. If the implementation does detect % 439 an error, the error is indicated. So if an error is detected, that error is "indicated". I think the indication must be in the usual way, by storing in errno (except for these unsual APIs where it is returned). This is already inconsistent with returning a specific error. I think nothing prevents detection of a different error (one not even listed in the ERRORS section) and nothing prevents returning that error, while the above requires it. % 440 For functions where no errors are defined, ``successful completion'' means that if the % 441 implementation checks for errors, no error has been detected. If the implementation can % 442 detect errors, and an error is detected, the indicated return value is returned and errno % 443 may be set. The only thing that is clear is that if an error is detected, the function cannot succeed. Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 21:34:09 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 771E6942 for ; Fri, 24 Jan 2014 21:34:09 +0000 (UTC) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B0431AB3 for ; Fri, 24 Jan 2014 21:34:08 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sweb; b=K2b4/MV2XrwbyFLpr7FYL8dX2K25P6W1D fduJxBKpxf/nHJPnUNcUiCVQxTdg+Vkdp7RkQ6mwXDAhxM3uGEY2hi8h6Iw4jSH2 xpeIPNxX3YOJ/fa1G3A0i9fzN1BqpoDMuxbAGuHesiPm7CP6y/KbYEMvFStUZWva XVvAzQE1cA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=sweb; bh=URfIPbyXaIvhl8agUKFFyqpA4ElOwRXLHUGA7Ug Cfus=; b=OzhMwfEO55TB5+Y2J6aLbRdeFCwfhErbWC24lydnyyOhV8EVUxW2Kz0 vXYMC0fGalnWoY6Guj9U3dtD8YY4BAmwOQ9rBlCuuCV4Ib1eQLNjXMM9Vd6wGon5 MURK0xH8Ua1h2pSXQNFP1IWennpr8QkwXdZl912+qRZcnaQ6vAWI= Received: (qmail 91505 invoked from network); 24 Jan 2014 15:34:05 -0600 Received: from unknown (HELO admin.xzibition.com) (bryan@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 24 Jan 2014 15:34:05 -0600 Date: Fri, 24 Jan 2014 15:34:04 -0600 From: Bryan Drewery To: Bruce Evans Subject: Re: closedir(3) handling NULL Message-ID: <20140124213404.GC73838@admin.xzibition.com> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> <20140125041504.Y986@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" Content-Disposition: inline In-Reply-To: <20140125041504.Y986@besplex.bde.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org, Jilles Tjoelker X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 21:34:09 -0000 --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 25, 2014 at 06:00:08AM +1100, Bruce Evans wrote: > On Fri, 24 Jan 2014, Bryan Drewery wrote: >=20 > > On Fri, Jan 24, 2014 at 02:24:35PM +0100, Jilles Tjoelker wrote: > >> On Thu, Jan 23, 2014 at 07:41:05PM -0600, Bryan Drewery wrote: > >>> I found that Linux handles closedir(NULL) fine and returns EINVAL. PO= SIX > >>> [1] specifies that EBADF should be returned if "The dirp argument does > >>> not refer to an open directory stream" > >> > >>> [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/closedir= =2Ehtml >=20 > > I do think that improving portability is important. Even against sloppy > > coding. Applications developed for Linux are fine passing NULL to close= dir(3), > > which leads to a style of coding that does not reveal itself to be a > > problem on FreeBSD until an edge case comes up. >=20 > This unimproves portability. FreeBSD intentionally does the opposite for > fclose(): from fclose(3): IMHO we should handle NULL gracefully in all places instead of having hidden surprises. >=20 > @ NOTES > @ The fclose() function does not handle NULL arguments; they will re= sult in > @ a segmentation violation. This is intentional - it makes it easie= r to > @ make sure programs written under FreeBSD are bug free. This behav= iour is > @ an implementation detail, and programs should not rely upon it. >=20 > It would be good to do the same thing for garbage stream pointers. [...] > % diff --git lib/libc/gen/closedir.c lib/libc/gen/closedir.c > % index 88ded37..d7a5bdb 100644 > % --- lib/libc/gen/closedir.c > % +++ lib/libc/gen/closedir.c > % @@ -53,6 +53,11 @@ fdclosedir(DIR *dirp) > % { > % int fd; > %=20 > % + if (dirp =3D=3D NULL) { > % + errno =3D EBADF; > % + return (-1); > % + } > % + >=20 > Style bug (extra blank line). >=20 > % if (__isthreaded) > % _pthread_mutex_lock(&dirp->dd_lock); >=20 > Example of normal style (no extra blank line after an if statement). >=20 > Extra blank lines are especially not needed after return statements since > return statements obviously don't fall through. >=20 > % fd =3D dirp->dd_fd; > % @@ -71,6 +76,10 @@ fdclosedir(DIR *dirp) > % int > % closedir(DIR *dirp) > % { > % + int fd; > % + > % + if ((fd =3D fdclosedir(dirp)) =3D=3D -1) > % + return (-1); > % >=20 > Style bug (extra blank line). >=20 > There is no man page for fdclosedir(3). It is in directory(3), but someo= ne > forgot to add fdclosedir.3 to MLINKS. fdopendir.3 is unsorted in MLINKS > instead of missing. Thanks for the style comments. I am now aware. I am fixing the MLINKS issues. >=20 > % - return (_close(fdclosedir(dirp))); > % + return (_close(fd)); > % } Bryan Drewery --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS4txLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNkZFQkU5OTJGNTI4MERGNDgxMTM2MkE2 RTc4MkFDMDNDOUIwQ0Y5AAoJEG54KsA8mwz5bT0P+QEJzLChOFBCg7IYb26thkhM lUy1L/EKwPiGDNQTrNUY4SiXhW0SuZDpa+8MkoRMT5yYqXbMpAOApJLt+2c5bYq0 88Q4TIyVPLnHC9HNM6wtneu802VNx2I2eN/xR4VU6SMKIiwI7mWglIWbi4IldnvI 8rsXb5l3rELrHduekyuJk2qbvY6NnBaL8JB7MJ4F4LDKrToYWV/ZBAiVSANDEcTA L9f27lRK8Z3JgPVngkdZMhU8x0Dmzho7AyJByfu+YxgPvhNSi7vlBBPbCasYTsIn vit/zLXB8zh26T1MPfMpSvK1ktFUt4nZ+aqfb7Pvv413oTRD3VVnaDetXX5gipI7 ZL1+GJuGr87IW0skvaM6MwaFqcASSyry7UNKW8JZoS7RjpW0wIRvvJw9wnMMnCER rxSKJNgVJe4QvWvha1IQrGQjBUlOMruAOWfRq5RhcSAd9UHMeHgjXJEoTBWVuuEW 4+Q3wkeU6/KGIp5546xglCqd7BXomS2yWZXinZe851latXXZfXlZHtgPJb0Dda4H bAzfTxMVoDPhQ/yLfPeph69CVSU+NQLWslnrWM3DGd0imD16o+t+gR3yhjA+GtJY /vWF7ZvYiQIPOzSA7BhLEETYCPwxfgRZeOxAfLjSiZArxhl16tvdPKAgFtrR9xk7 psJzIJ0fwXnVOsli9tUn =8/QF -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- From owner-freebsd-standards@FreeBSD.ORG Fri Jan 24 22:39:21 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB8FB341; Fri, 24 Jan 2014 22:39:21 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6DA28101F; Fri, 24 Jan 2014 22:39:21 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id DC283359306; Fri, 24 Jan 2014 23:39:18 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id CB31228497; Fri, 24 Jan 2014 23:39:18 +0100 (CET) Date: Fri, 24 Jan 2014 23:39:18 +0100 From: Jilles Tjoelker To: Bryan Drewery Subject: Re: closedir(3) handling NULL Message-ID: <20140124223918.GA97844@stack.nl> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> <20140125041504.Y986@besplex.bde.org> <20140124213404.GC73838@admin.xzibition.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140124213404.GC73838@admin.xzibition.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:39:21 -0000 On Fri, Jan 24, 2014 at 03:34:04PM -0600, Bryan Drewery wrote: > On Sat, Jan 25, 2014 at 06:00:08AM +1100, Bruce Evans wrote: > > On Fri, 24 Jan 2014, Bryan Drewery wrote: > > > I do think that improving portability is important. Even against > > > sloppy coding. Applications developed for Linux are fine passing > > > NULL to closedir(3), which leads to a style of coding that does > > > not reveal itself to be a problem on FreeBSD until an edge case > > > comes up. > > This unimproves portability. FreeBSD intentionally does the > > opposite for fclose(): from fclose(3): > IMHO we should handle NULL gracefully in all places instead of having > hidden surprises. In many cases (but possibly not this one), handling NULL "gracefully" makes it harder to debug the inevitable failure. For example, if readdir() did not crash when passed a null pointer, a program that fails to check opendir()'s return value would plough on for longer and it would be harder to find the problem. Whether a function that frees something silently does nothing when passed a null pointer is indeed inconsistent. -- Jilles Tjoelker From owner-freebsd-standards@FreeBSD.ORG Sat Jan 25 01:29:36 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org 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 AEFD08D0 for ; Sat, 25 Jan 2014 01:29:36 +0000 (UTC) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53D0C1E69 for ; Sat, 25 Jan 2014 01:29:36 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sweb; b=ObeFlSIJYncf0ERgbM6yDtBMn6RAtGjzQ FPlQXRQCeXEfzTfOSTqMvVlAd/kjZMhbqgTNpJXqDdC+n4MkxuCAYIhNhFKn49dD FgJIkyGqTJheqZW7ygwoJbFa2FqjTYccWA5pYtyT7KqWSEaf5Qho0dQboOjh7pNi GOuFfUvkTo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=sweb; bh=K2hY2G/AnHEuOOBCrOZ5jQkDxcR7IuYf286mqaF xaEs=; b=jpYuck2cFWccD0NlNIN5gXGRPsZUKcgDbeR3GuI71LMgAWxdEeIMhJ9 2bq4XjzWxWw/oAEH1CzsmsZzsVgrnBmY5lImkmUsSc8dwOg9kPr8W8a6Et5PHt/h rW6Uh6vy9t4QhY2qZAmw7u953HJ7aUyxlcBTsuadGwCM72nxQo5M= Received: (qmail 77820 invoked from network); 24 Jan 2014 19:29:34 -0600 Received: from unknown (HELO admin.xzibition.com) (bryan@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 24 Jan 2014 19:29:34 -0600 Date: Fri, 24 Jan 2014 19:29:32 -0600 From: Bryan Drewery To: Jilles Tjoelker Subject: Re: closedir(3) handling NULL Message-ID: <20140125012932.GD73838@admin.xzibition.com> References: <20140124014105.GC37334@admin.xzibition.com> <20140124132435.GA90996@stack.nl> <20140124165509.GA73838@admin.xzibition.com> <20140125041504.Y986@besplex.bde.org> <20140124213404.GC73838@admin.xzibition.com> <20140124223918.GA97844@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SFyWQ0h3ruR435lw" Content-Disposition: inline In-Reply-To: <20140124223918.GA97844@stack.nl> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 01:29:36 -0000 --SFyWQ0h3ruR435lw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2014 at 11:39:18PM +0100, Jilles Tjoelker wrote: > On Fri, Jan 24, 2014 at 03:34:04PM -0600, Bryan Drewery wrote: > > On Sat, Jan 25, 2014 at 06:00:08AM +1100, Bruce Evans wrote: > > > On Fri, 24 Jan 2014, Bryan Drewery wrote: > > > > I do think that improving portability is important. Even against > > > > sloppy coding. Applications developed for Linux are fine passing > > > > NULL to closedir(3), which leads to a style of coding that does > > > > not reveal itself to be a problem on FreeBSD until an edge case > > > > comes up. >=20 > > > This unimproves portability. FreeBSD intentionally does the > > > opposite for fclose(): from fclose(3): >=20 > > IMHO we should handle NULL gracefully in all places instead of having > > hidden surprises. >=20 > In many cases (but possibly not this one), handling NULL "gracefully" > makes it harder to debug the inevitable failure. For example, if > readdir() did not crash when passed a null pointer, a program that fails > to check opendir()'s return value would plough on for longer and it > would be harder to find the problem. >=20 > Whether a function that frees something silently does nothing when > passed a null pointer is indeed inconsistent. This argument makes sense to me. Stating the obvious, it's unfortunate that POSIX leaves some behavior undef= ined that leads to these inconsistencies between systems. >=20 > --=20 > Jilles Tjoelker > _______________________________________________ > freebsd-standards@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-standards > To unsubscribe, send any mail to "freebsd-standards-unsubscribe@freebsd.o= rg" --SFyWQ0h3ruR435lw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS4xN8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNkZFQkU5OTJGNTI4MERGNDgxMTM2MkE2 RTc4MkFDMDNDOUIwQ0Y5AAoJEG54KsA8mwz5sV4P/iiOf4w8vbkIy760kwjIQKDl oViICQsLTcHFu0HwSZaL/Gbg7O83pJQjxw8/oXCg4O3YhBxgmhEyOH7UFnE9wxKe +Sjd646xLhI/h9l4HDn4Tf0YsFoa+OINllNgakmuZry1v8+GwbMu38P0hXhgF8RR CPepPLgCDsWVXfnNnHwSiYMrVd8oCRRPSsgIX6fgwEudRIThzYdJBaRomUbzy5sG nNySRHZqShx5daVw3QszBaHEl/4OA2FdqSP66UZaT7i8f4JFRu3tbYWavkGSkQwp GCjRS/coOX0nzASansT9LqEhr4oQFSJQNYLI7hfVs7BCjQHCqOKU3l0r1DZUlx2O FcxXmcBEXdeRZfYQeq0787MvwJUf4Nrkxrghk4Di7+w97Fy3M9cDRcNIw9skwF8D dDrYUE4JnPrmW0eZBWLqt3RdRnIyJUV3d4FFvPPNHNfZRnkAP6XMZ3Ak3q2b+ghp 3iMPnBGIm3d25oR5ql4EVUU/xfKCcoWKAO+ZEuOLBOltEQxKeWGAasMKQyTvNIBy MKjxFmn3E9aLPfEqPhsd4wCY6uhRsTmu41Fg3+kcCqxz5h9VTH1skX7YFEZ72FED I5AECfDK47uYR43nOnSrL1RPy4odSnf6E+XqpankEoAnzKlGkh1ILwbe4UUiu/i0 GzeQNrnhWogQADAvKsKk =lcLW -----END PGP SIGNATURE----- --SFyWQ0h3ruR435lw--