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=