Date: Wed, 1 Jun 2005 17:11:54 +0200 (CEST) From: Harti Brandt <hartmut.brandt@dlr.de> To: freebsd-arch@FreeBSD.org Cc: delphij@delphij.net Subject: Re: [PATCH RFC] Add a macro for null mount options to sbin/mount* Message-ID: <20050601170858.V51549@beagle.kn.op.dlr.de> In-Reply-To: <20050601150344.GA39784@dragon.NUXI.org> References: <1117613456.771.16.camel@spirit> <20050601150344.GA39784@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 1 Jun 2005, David O'Brien wrote:
DO>On Wed, Jun 01, 2005 at 04:10:56PM +0800, Xin LI wrote:
DO>> Hi, -arch@,
DO>>
DO>> In our mount* utilities, the null mount option, which is usually be used
DO>> as a terminator of an option vector, is defined with some hand-rolled
DO>> terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.
DO>>
DO>> I think it would be nice to have a new macro to deal with this, say,
DO>> MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
DO>> an explicit initialize. And in my opinion, something like:
DO>
DO>I think it is better to leave it alone. The "NULL" termination of a list
DO>like this is a C idiom that should be clear to any C programmer. Hiding
DO>the details in a macro (is MOPT_NULL an integer or a sentinel?) makes it
DO>harder to see the idiom and know exactly what is going on and how this
DO>list will be processed.
The problem is that with the right set of warning options gcc will warn if
you write {NULL}, but there are more fields than just a pointer. If the
structure definition is stable enough this is no problem - just go through
all the programs and fix it once. If the definition is likely to change
from time to time, a macro is better because it just does the right thing.
harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050601170858.V51549>