From owner-freebsd-standards@FreeBSD.ORG Mon Jan 27 02:44:47 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 5F797CF for ; Mon, 27 Jan 2014 02:44:47 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 227EC14E1 for ; Mon, 27 Jan 2014 02:44:46 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id hl1so7820489igb.1 for ; Sun, 26 Jan 2014 18:44:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=lvTjhCxk3Z8+IfA4h4OTHPg2DDGrvmD6reys/IOWpGg=; b=VqIJ+d/8OvKDazJZDcIqJZ3JQwHme7mzVbKpfRjpc9FsG+RVbY/YqqVW7+5MXKNhFl Wg0b6Pq5JAnQGZSwGY0zcMLlvIrCvhPOthfc0tfZ6krb9NDUnCr7Sw1EYjwrXgJExn/3 ioEzLWsTQQhzc2tieItLzjljTL26SIxqq5i+PhR9x7RLIyYlzRAQ4H5SCLEkEaamyr0T lJCmL3mOLRB0mz3ImskT3AJmAgBoeFHdKmXWwVhbS9tStrmk5qOoFEGnxk7gRyN92D3X 2QKN25tY8SJU35A3d00fmCL5h5t1p6ZKrL80vN+NVqtkEDAiSUxWKrQHi2u4RUG5xRuk vo0g== X-Gm-Message-State: ALoCoQnCNQ2trDa/enHJaCqUJGHpGmugBm7XrZUhit40kMxDGqdw9FwlnIcJobtcxZaKJY8USvWZ X-Received: by 10.50.18.41 with SMTP id t9mr5340190igd.26.1390790686244; Sun, 26 Jan 2014 18:44:46 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id kz4sm23722397igb.4.2014.01.26.18.44.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 18:44:45 -0800 (PST) Sender: Warner Losh Subject: Re: closedir(3) handling NULL Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <2E6DB94B-C2C3-4798-912C-0E65B070DBC6@bsdimp.com> Date: Sun, 26 Jan 2014 19:44:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <20140124180635.GN24664@kib.kiev.ua> <20140127020624.GE52772@neutralgood.org> <2E6DB94B-C2C3-4798-912C-0E65B070DBC6@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1085) Cc: bapt@FreeBSD.org, Jilles Tjoelker , freebsd-standards@FreeBSD.org, Bryan Drewery 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, 27 Jan 2014 02:44:47 -0000 On Jan 26, 2014, at 7:38 PM, Warner Losh wrote: >=20 > On Jan 26, 2014, at 7:06 PM, kpneal@pobox.com wrote: >=20 >> On Fri, Jan 24, 2014 at 08:06:35PM +0200, Konstantin Belousov wrote: >>> On Fri, Jan 24, 2014 at 11:49:39AM -0600, Bryan Drewery wrote: >>>>=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? >>>=20 >>> Ok, so it does not have much to do with unmount, it is just an open >>> of nonexistent path. >>>=20 >>> 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. >>=20 >> Wasn't free() accepting NULL a change that came in with C99? I = thought >> that before then free() was only required to take valid pointers that = came >> from one of the malloc() functions. So some systems accepted NULL and = some >> did not. >=20 > No. C89 mandated free(NULL) to be a well defined nop. Can you give an = example of one that conforms to Ansi C? It was unspecified in K&R first = edition though. >=20 > =46rom "7.20.3.2 The free function" > ... > "void free(void *ptr); >=20 > The free function causes the space pointed to by ptr to be = deallocated, that is, made > available for further allocation. If ptr is a null pointer, no action = occurs." >=20 > K&R I (1988) says >=20 > "7.8.5 Storage Management > ... > free(p) frees the space pointed to by p, where p was originally = obtained by a call to malloc or=20 > calloc. There are no restrictions on the order in which space is = freed, but it is a ghastly error to free=20 > something not obtained by calling malloc or calloc. " >=20 > Which is silent on the issue, although a null pointer is a pointer = that can be returned from malloc (either as an error or as the = unspecified behavior of malloc(0)). Early implementations varied widely = in their behavior. bsd tended to favor 'dump core' while sys v favored = the 'nop' behavior because it returned a null pointer for malloc(0). >=20 > So it has been well defined for 25 years: free(NULL) is a nop. Hate to followup to my own post, but in the appendix reference section I = have: B.5 Utility Functions: void free(void *p)=20 free deallocates the space pointed to by p; it does nothing if p is = NULL. p must be a pointer to=20 space previously allocated by calloc, malloc, or realloc.=20 But it turns out that this is 2nd edition K&R (ANSI version)...= From owner-freebsd-standards@FreeBSD.ORG Mon Jan 27 02:46:06 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 94862192 for ; Mon, 27 Jan 2014 02:46:06 +0000 (UTC) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5938414F0 for ; Mon, 27 Jan 2014 02:46:06 +0000 (UTC) Received: by mail-ig0-f170.google.com with SMTP id m12so10106439iga.1 for ; Sun, 26 Jan 2014 18:46:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=okN+XHtKwUVcjfogIg6W+ges4/8qyHlBVw4v9oGWVFA=; b=dHXYi8skdFeEG7/1B7E3axM0JodDpC8u67GUdiA2KztAm3m7phkRYmY6ujmelOWQEN VUGr9IirF6BZ28tA523B3G435ear0ySvbmdwnSxT86h3cXyvnbNS+fVSkLWiumhyBmqX AaOSr00ilUJ+l6atnBB9WbSHr6vr7f0E28aujZ4lAqxt/aUg63EzZ6dSxA6cza+x5hvS NJAJr7oh0eLh3D+SX9IDfB/ZfX9zRg28z7ZyQ5eoHT5Zeu2vXCr8ru839qToy009mWab Sgwk3ZD6ID6WXkvEoB5tZ9PQyAtHraqJhoGKa1mrsGW6KFQNLtBbLFHk5R+XXjLed1rE sqmA== X-Gm-Message-State: ALoCoQlNPj3Gd1o/7zAhxmgAhgHgfb0NQNOh1pqiSD9i2/48dSxYBOJdqxtyBAf/2jmzxQVBpU/0 X-Received: by 10.50.43.162 with SMTP id x2mr15349781igl.39.1390790317561; Sun, 26 Jan 2014 18:38:37 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ml2sm38167052igb.10.2014.01.26.18.38.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 18:38:36 -0800 (PST) Sender: Warner Losh Subject: Re: closedir(3) handling NULL Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140127020624.GE52772@neutralgood.org> Date: Sun, 26 Jan 2014 19:38:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E6DB94B-C2C3-4798-912C-0E65B070DBC6@bsdimp.com> 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> <20140124180635.GN24664@kib.kiev.ua> <20140127020624.GE52772@neutralgood.org> To: kpneal@pobox.com X-Mailer: Apple Mail (2.1085) Cc: bapt@FreeBSD.org, freebsd-standards@FreeBSD.org, Jilles Tjoelker , Bryan Drewery 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, 27 Jan 2014 02:46:06 -0000 On Jan 26, 2014, at 7:06 PM, kpneal@pobox.com wrote: > On Fri, Jan 24, 2014 at 08:06:35PM +0200, Konstantin Belousov wrote: >> On Fri, Jan 24, 2014 at 11:49:39AM -0600, Bryan Drewery wrote: >>>=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? >>=20 >> Ok, so it does not have much to do with unmount, it is just an open >> of nonexistent path. >>=20 >> 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. >=20 > Wasn't free() accepting NULL a change that came in with C99? I thought > that before then free() was only required to take valid pointers that = came > from one of the malloc() functions. So some systems accepted NULL and = some > did not. No. C89 mandated free(NULL) to be a well defined nop. Can you give an = example of one that conforms to Ansi C? It was unspecified in K&R first = edition though. =46rom "7.20.3.2 The free function" ... "void free(void *ptr); The free function causes the space pointed to by ptr to be deallocated, = that is, made available for further allocation. If ptr is a null pointer, no action = occurs." K&R I (1988) says "7.8.5 Storage Management ... free(p) frees the space pointed to by p, where p was originally obtained = by a call to malloc or=20 calloc. There are no restrictions on the order in which space is freed, = but it is a ghastly error to free=20 something not obtained by calling malloc or calloc. " Which is silent on the issue, although a null pointer is a pointer that = can be returned from malloc (either as an error or as the unspecified = behavior of malloc(0)). Early implementations varied widely in their = behavior. bsd tended to favor 'dump core' while sys v favored the 'nop' = behavior because it returned a null pointer for malloc(0). So it has been well defined for 25 years: free(NULL) is a nop. Warner= From owner-freebsd-standards@FreeBSD.ORG Mon Jan 27 11:06:55 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 5CD2FD28 for ; Mon, 27 Jan 2014 11:06:55 +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 45AC81A97 for ; Mon, 27 Jan 2014 11:06:55 +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 s0RB6tfA013162 for ; Mon, 27 Jan 2014 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0RB6sF1013160 for freebsd-standards@FreeBSD.org; Mon, 27 Jan 2014 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Jan 2014 11:06:54 GMT Message-Id: <201401271106.s0RB6sF1013160@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, 27 Jan 2014 11:06:55 -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/186028 standards incorrect return values for posix_fallocate() 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 47 problems total. From owner-freebsd-standards@FreeBSD.ORG Thu Jan 30 00:52: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 73BAD263 for ; Thu, 30 Jan 2014 00:52: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 0A2831E7E for ; Thu, 30 Jan 2014 00:52:11 +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 :content-transfer-encoding:in-reply-to; q=dns; s=sweb; b=Q++qNOO w9HQSeR/MIAk5Y3aIuQM0PhvyzOoTjbRvkgHouG+QedLiUlGTS/dcfEqe/DZ+bC8 YrClB2XUxZdNMMuV9dyTGDP84cVu259LRXAqvc6KdtUekaLGHs6sg6dmOUtNqRJi CX4TVOFSG8V1UmaQ08m1bJLh95txIPb60nLk= 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 :content-transfer-encoding:in-reply-to; s=sweb; bh=tl8tgvXk0sy5v lgSvPEZDVZjZdNeVmPKW5t8q78MzuU=; b=mihmYdkbzByAzXbNbEVORFkd3MCAB NqpB1x4mSCnDPFZbtSMbrsmcuQO7qlvJPGvl+xILPP46eCfL+PHTwrLxzA3V8n0X 9kFdfBKSZaXPskgs1BWwNELEjqsm9xMqdgRLISfEd+51uKQinqwvxFnIleqagi6y yX3bAngWRhR3mk= Received: (qmail 93748 invoked from network); 29 Jan 2014 18:52:03 -0600 Received: from unknown (HELO admin.xzibition.com) (bryan@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 29 Jan 2014 18:52:03 -0600 Date: Wed, 29 Jan 2014 18:51:59 -0600 From: Bryan Drewery To: Jilles Tjoelker Subject: Re: closedir(3) handling NULL Message-ID: <20140130005159.GA34611@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: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: Thu, 30 Jan 2014 00:52:12 -0000 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. So I've thought about this more and I don't think closedir(NULL) or fclose(NULL) actually hide any issue except subjective sloppy code. I still point out that free(NULL) is fine, so it seems consistent to do the same on other deallocation functions. When I say we should handle NULL gracefully I really only mean in deallocations. Thus realpath(3) and time(3) are not in my suggestion. (It is odd that it accepts NULL though). I do realize that free(NULL) is a different standard, but that is not relevant from the perspective of the developer writing the code, or one who is used to Linux behavior and porting to FreeBSD. If they are writing it to the standards they will assume nothing and not call closedir(NULL). But if they come from Linux they may have people around them reviewing their code asking why they are checking for NULL before closedir(3) and fclose(3). I'm not sure what the common knowledge is on it. I did find that glibc has accepted closedir(NULL) since 1995, and fclose(NULL) since 1997*. POSIX states that [EBADF] "may" return on a dirp not referring to an open stream. NULL doesn't refer to an open stream, which fits. However, due to not being able to easily implement closedir(random) returning [EBADF] it makes sense to me to not return [EBADF] on NULL as then we are essentially claiming to support that clause. I noticed that Linux manpage claims to support [EBADF] for invalid directory stream. I dug into glibc and found that it is just returning [EBADF] from close(2). Ours does the same as Jilles pointed out. So technically it can be returned already and we should probably document that. Incidentally fclose.3 used to document [EBADF] and no longer does since r40178, despite being a possible error. And note that fpurge(3) uses the same logic for returning [EBADF] as fclose(3) and still has it documented in fpurge.3. We do keep this documented in fflush.3 (a different check is done to determine as fclose(3) does). Undocumented features/flags are doc bugs. As closedir(NULL) is undefined, then I see it as up to us to decide how to deal with it. The consensus seems to be that it should crash, but I am surprised by that and confused why that position is defended. The purpose of POSIX is to improve portability and lessen the amount of differences in systems right? We try to be a POSIX compliant system. Since POSIX does not define how NULL should be handled, any choice we pick is still compliant. Right? If this is not a standards issue, should I take this to arch@? I would make this argument more about portability with Linux, and being consistent with free(NULL). glibc has returned [EINVAL] for closedir(NULL) since at least 1995. glibc's fclose(NULL) would close all streams up until 1997 when it was changed to return [EINVAL] on NULL when fcloseall(3) was added. As surprising as it sounds, I was under the impression free(NULL) would crash until recently, and I've been writing C for 15 years or so. Somehow I picked up an application and they had it as their style and I must have done a free(ptr->obj) at some point and had a NULL ptr and learned the wrong lesson. So now that I realize free(NULL) is OK, it is strange to me that we are not OK with other functions working the same. Let me lay out some examples here to try to understand why fclose(NULL) or closedir(NULL) would hinder debugging. Case 1: DIR *dirp; struct dirent *dp; dirp =3D opendir("/nonexistent"); dp =3D dirent(dirp); /* SIGSEGV, closedir(NULL) never reached */ closedir(dirp); /* Sloppy code gets expected poor results on failures. */ Case 2: DIR *dirp; struct dirent *dp; dirp =3D opendir("/etc/passwd"); dp =3D dirent(dirp); closedir(dirp); /* Sloppy, but all fine. Similar to case 1, it would crash on line 5 if file not found. */ Case 3: DIR *dirp; struct dirent *dp; if ((dirp =3D opendir("/nonexistent")) !=3D NULL) { dp =3D dirent(dirp); /* ... */ } closedir(dirp); /* All is fine, code does not and should not crash. If we kept closedir(NULL) as crashing, the "fix" would be to move closedir() up 1 line. It's a hidden surprise. (POLA?) */ Case 4: DIR *dirp; struct dirent *dp; if ((dirp =3D opendir("/etc/passwd")) !=3D NULL) { dp =3D dirent(dirp); /* ... */ } closedir(dirp); /* All is fine. */ Case 5: DIR *dirp; struct dirent *dp; if ((dirp =3D opendir("/etc/passwd")) !=3D NULL) { dp =3D dirent(dirp); /* ... */ closedir(dirp); } /* All is fine; unaffected by proposed change */ Did I miss a case? For closedir(2) it seems irrelevant for debugging to crash. I've reviewed all consumers of DIR* and FILE* in lib/libc for object dereference. Except for the exceptions below, all do dereference the object passed to them. It would be strange if they did not. Thus the program would still crash, and much earlier than closedir(NULL) or fclose(NULL) would. Exceptions: fflush(3) accepts NULL and will flush all buffers if used. I don't see this as a big deal if somehow it is accidentally passed a NULL. An earlier call with fwrite(3) etc. should have already crashed anyhow. freopen(NULL) will fclose(NULL) and return an error if passed improper modes. It returns NULL and EINVAL. A subsequent call to use the FILE* will fail. setvbuf(NULL) can silently ignore NULL and return EOF if passed invalid arguments. Invalid mode or size<0. Otherwise it properly dereferences fp. The only one I see as having the "keep going" problem is freopen(3), but even that is when passing in invalid modes and would be pretty rare. It's very likely that the next line of code would be trying to use that object somehow and would then crash anyway. So, I believe the debugging and "purposeful crash" argument is bogus and should be removed either way from fclose.3. Perhaps it's *really* a leftover behavior from fclose(NULL)->fcloseall(). I am not sure if our fclose(3) behaved like that ever. The BSD4.4 import did not, but Bruce mentions it and glibc used to behave like that. Regardless, I can see how that perhaps would cause an invalid behavior, closing all buffers when just 1 failed to open. But that is very historical. >=20 > Whether a function that frees something silently does nothing when > passed a null pointer is indeed inconsistent. >=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" From owner-freebsd-standards@FreeBSD.ORG Thu Jan 30 14:20: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 BD100E4B for ; Thu, 30 Jan 2014 14:20: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 98983110E for ; Thu, 30 Jan 2014 14:20: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 s0UEK0Sx040331 for ; Thu, 30 Jan 2014 14:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0UEK0L4040330; Thu, 30 Jan 2014 14:20:00 GMT (envelope-from gnats) Resent-Date: Thu, 30 Jan 2014 14:20:00 GMT Resent-Message-Id: <201401301420.s0UEK0L4040330@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, mahbubul alam 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 37222D06 for ; Thu, 30 Jan 2014 14:15:51 +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 0A84010DE for ; Thu, 30 Jan 2014 14:15:51 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id s0UEFoI0099854 for ; Thu, 30 Jan 2014 14:15:50 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id s0UEFnbf099849; Thu, 30 Jan 2014 14:15:49 GMT (envelope-from nobody) Message-Id: <201401301415.s0UEFnbf099849@oldred.freebsd.org> Date: Thu, 30 Jan 2014 14:15:49 GMT From: mahbubul alam To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: standards/186275: fraud 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, 30 Jan 2014 14:20:00 -0000 >Number: 186275 >Category: standards >Synopsis: fraud >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Jan 30 14:20:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: mahbubul alam >Release: sussex ward >Organization: citizen >Environment: hungry >Description: prison inplant still >How-To-Repeat: prison inplant redused >Fix: prison inplant tannsmission elecronic >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Thu Jan 30 14:49:57 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 8E3BF71C; Thu, 30 Jan 2014 14:49:57 +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 5DF7C1361; Thu, 30 Jan 2014 14:49:57 +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 s0UEnvwO046478; Thu, 30 Jan 2014 14:49:57 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0UEnubT046474; Thu, 30 Jan 2014 14:49:56 GMT (envelope-from eadler) Date: Thu, 30 Jan 2014 14:49:56 GMT Message-Id: <201401301449.s0UEnubT046474@freefall.freebsd.org> To: makaalam@yahoo.co.uk, eadler@FreeBSD.org, freebsd-standards@FreeBSD.org From: eadler@FreeBSD.org Subject: Re: standards/186275: fraud 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, 30 Jan 2014 14:49:57 -0000 Synopsis: fraud State-Changed-From-To: open->closed State-Changed-By: eadler State-Changed-When: Thu Jan 30 14:49:56 UTC 2014 State-Changed-Why: Committed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=186275 From owner-freebsd-standards@FreeBSD.ORG Thu Jan 30 14:50:11 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 41E26749; Thu, 30 Jan 2014 14:50:11 +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 15E3E1365; Thu, 30 Jan 2014 14:50:11 +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 s0UEoAHS046695; Thu, 30 Jan 2014 14:50:10 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0UEoAMu046694; Thu, 30 Jan 2014 14:50:10 GMT (envelope-from eadler) Date: Thu, 30 Jan 2014 14:50:10 GMT Message-Id: <201401301450.s0UEoAMu046694@freefall.freebsd.org> To: makaalam@yahoo.co.uk, eadler@FreeBSD.org, freebsd-standards@FreeBSD.org, gnats-adm@FreeBSD.org From: eadler@FreeBSD.org Subject: Re: junk/186275: fraud 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, 30 Jan 2014 14:50:11 -0000 Synopsis: fraud State-Changed-From-To: open->closed State-Changed-By: eadler State-Changed-When: Thu Jan 30 14:50:08 UTC 2014 State-Changed-Why: junky junk junk Responsible-Changed-From-To: freebsd-standards->gnats-adm Responsible-Changed-By: eadler Responsible-Changed-When: Thu Jan 30 14:50:08 UTC 2014 Responsible-Changed-Why: junky junk junk http://www.freebsd.org/cgi/query-pr.cgi?pr=186275 From owner-freebsd-standards@FreeBSD.ORG Thu Jan 30 17:52:37 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 9D35FB16; Thu, 30 Jan 2014 17:52:37 +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 3D6F3148D; Thu, 30 Jan 2014 17:52:37 +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 s0UHqTN1085998; Thu, 30 Jan 2014 19:52:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s0UHqTN1085998 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s0UHqQEd085997; Thu, 30 Jan 2014 19:52:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 30 Jan 2014 19:52:26 +0200 From: Konstantin Belousov To: Bruce Evans Subject: Re: standards/186028: incorrect return values for posix_fallocate() Message-ID: <20140130175226.GW24664@kib.kiev.ua> References: <201401230858.s0N8wwQB039907@oldred.freebsd.org> <20140123094017.GH24664@kib.kiev.ua> <20140124181246.GO24664@kib.kiev.ua> <20140125062048.R1518@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lGQpFNrcSq0Rb43w" Content-Disposition: inline In-Reply-To: <20140125062048.R1518@besplex.bde.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: 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: Thu, 30 Jan 2014 17:52:37 -0000 --lGQpFNrcSq0Rb43w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 25, 2014 at 06:46:16AM +1100, Bruce Evans wrote: > 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: >=20 > [#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. >=20 > 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. >=20 > 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. Yes, this is question of quality. posix_madvise(2) should behave like a syscall. > 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. I document the implementation. If somebody could provide the better wording, I cannot object. For now, I am going to commit the existing patch. --lGQpFNrcSq0Rb43w Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJS6pFZAAoJEJDCuSvBvK1BRb0P/3Nvu7eXvK0+RfkOOUfZBuOc SHSCbkjahEUw/VqiWXR96yLsHVSqhZFdEfObkG9IY3ErNElGNT4/ifJrMjrfxuUX drfTK48DL8tkNE1YfzBK2qwsB1FUWo1ZxB89cqOhV5GZ49cUnivtV88G22NYXw5z 8tsjpyJEgTrl7pUDlaAzB99/9Lr7000jTIhGYG9eRTtede+Jes/uybChDeQHoso0 ilrLYenhVB0blsvvks8kzIK5bkCSPsWQh4515lhID/ERL0H8a1zr32HGYncEkZ1g HliyF0FevrfuscYtsIMwbXOkfbUR07LO8qxWXeMZ/rWR7PWxO9kdimnnvBRhNE4z 4vXMCQ0kxdlEHHbEKrc+1O1geVsBuZZ7cnNP4VPw5wDuRmF/F8w/S7XG3BHXK9B6 +HsdQi6yxBFnLR3YqZE6MLg81FVtWMUP8X33yjuMC+aADUR2K3W2IOHOHvixiKFB 8LQ06oxARKvKQ6/38JjMXvLBoyZt6oiYmuqDIDaNRHcD+40vdqKxCtOZz+PwNPnm 20q1N0AXkO8WX5b4S31xWSPR/GDkp6Rwjl9KVaAqjbOErgZdMqriNT616PBR3kvN 2XWuIeZTieg1OewKgycHucbK0roAuB3+Wsp0aFSHIdUGceVsaB/W01CRf0qHXDRs a5EZfH4GyDyzEWJ0J9Mx =CjaO -----END PGP SIGNATURE----- --lGQpFNrcSq0Rb43w--