Date: Sat, 4 Dec 2010 21:06:32 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Eygene Ryabinkin <rea@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au>, Bruce Cran <brucec@freebsd.org> Subject: Re: svn commit: r216143 - in head: share/man/man9 sys/amd64/include sys/arm/include sys/i386/include sys/ia64/include sys/mips/include sys/pc98/include sys/powerpc/include sys/sparc64/include sys/sun4v... Message-ID: <20101204204755.C1958@besplex.bde.org> In-Reply-To: <cEbDex9rRdSmKUpxrYLwdIVvssg@QsmfhJNucgI88DfvPJdT1/nyboE> References: <201012030709.oB379NOH058721@svn.freebsd.org> <20101204045754.T4046@besplex.bde.org> <cEbDex9rRdSmKUpxrYLwdIVvssg@QsmfhJNucgI88DfvPJdT1/nyboE>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Dec 2010, Eygene Ryabinkin wrote: > Sat, Dec 04, 2010 at 05:01:55AM +1100, Bruce Evans wrote: >> On Fri, 3 Dec 2010, Bruce Cran wrote: >>> Log: >>> Revert r216134. This checkin broke platforms where bus_space are macros: >>> they need to be a single statement, and do { } while (0) doesn't >>> work in this situation so revert until a solution can be devised. >> >> Surprising that do-while doesn't work. > > Prior to the revert, something like "a = bus_space_read_multi_1(...)" > will generate improper code like "a = KASSERT(); __bs_nonsigle(XXX);" > and making "do { KASSERT(); __bs_nonsingle(XXX); } while(0)" won't > help either, since we can't generally assign the compound statement > to the lvalue. Ah, the functions actually return something :-). >> I just noticed the following possibly more serious problems for the macro >> versions: >> >> - the `c' arg is missing parentheses in the KASSERT() >> - the `c' arg is now evaluated twice. This turns safe macros into unsafe >> ones. > > Perhaps we can define the macros as > {{{ > #define bus_space_read_multi_1(t, h, o, a, c) ({\ > size_t count = (c); \ > KASSERT(count != 0, ("bus_space_read_multi_1: count == 0")); \ > __bs_nonsingle(rm,1,(t),(h),(o),(a),count); \ > }) > }}} > > This will both allow to avoid unsafety and will make this statement > to be the correct assignment for any compiler that supports the > "braced-groups within expressions" GNU extension. GNU C, Clang > and Intel C both support it (but not with -pedantic -ansi -Werror > flag combo). This is why amd64 and i386 use __extension when they use statement-expressions. grep in -current shows 32 .h files under /sys matching "({", and only 7 of these files use __extension. It is mostly headers visible in userland that are careful. sparc64 and sun4v atomic.h seem to be the only headers that both use ({ and are used in userland. For .c files, statement-expressions are remarkably little-used -- there are more line 32 lines total matching "({", and 0 lines matching "__extension". > But, probably, the inline function will be better here from the > portability point of view, since it is supported by the C standard > and braced-groups -- aren't. > > So, the question is "why these statements were made to be > macros at some platforms?". I guess it is just because they seemed to be simple enough to be macros. Macros and inline have different technical advantages but I don't see any important ones here. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101204204755.C1958>