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)...=