From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sd0gP-0000X1-7k for qemu-devel@nongnu.org; Fri, 08 Jun 2012 11:01:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sd0gI-0006RH-Rh for qemu-devel@nongnu.org; Fri, 08 Jun 2012 11:01:00 -0400 Date: Sat, 9 Jun 2012 00:15:02 +1000 From: David Gibson Message-ID: <20120608141502.GG6614@truffala.fritz.box> References: <1338940402-28502-1-git-send-email-agraf@suse.de> <1338940402-28502-3-git-send-email-agraf@suse.de> <1338958867.15420.4.camel@PetaLogix-ws2> <4FCF7D7E.8050907@suse.de> <4FCFD139.5040504@freescale.com> <20120606234511.GD6614@truffala.fritz.box> <20120607121318.GF6614@truffala.fritz.box> <61CC6CB0-DBA1-4EF3-9F5E-09F076048AE1@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61CC6CB0-DBA1-4EF3-9F5E-09F076048AE1@suse.de> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 02/31] dt: add helpers for 2, 3 and 4 cell adds List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Scott Wood , Peter Crosthwaite , qemu-ppc Mailing List , "qemu-devel@nongnu.org Developers" On Fri, Jun 08, 2012 at 03:00:56PM +0200, Alexander Graf wrote: > > On 07.06.2012, at 14:13, David Gibson wrote: > > > On Thu, Jun 07, 2012 at 01:27:56PM +0200, Alexander Graf wrote: > >> > >> On 07.06.2012, at 01:45, David Gibson wrote: > >> > >>> [snip] > >>>>> You mean internally? Yeah, probably. Externally? The point of these > >>>>> helpers is to make the code look less cluttered. We can already pass in > >>>>> an array just fine, but C is quite annoying about generating those on > >>>>> the fly, while it's easy to pass in ints as parameters :) > >>>> > >>>> Varargs? > >>> > >>> Ugly and risky with standard C varargs (because an explicit length > >>> would be needed). Could be done neatly with gcc macro varargs. > >> > >> Could a combination of both like this work? > >> > >> #include > >> #include > >> > >> #define __VA_NARG__(...) \ > >> (__VA_NARG_(_0, ## __VA_ARGS__, __RSEQ_N()) - 1) > >> #define __VA_NARG_(...) \ > >> __VA_ARG_N(__VA_ARGS__) > >> #define __VA_ARG_N( \ > >> _1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \ > >> _11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \ > >> _21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \ > >> _31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \ > >> _41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \ > >> _51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \ > >> _61,_62,_63,N,...) N > >> #define __RSEQ_N() \ > >> 63, 62, 61, 60, \ > >> 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, \ > >> 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, \ > >> 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, \ > >> 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, \ > >> 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, \ > >> 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 > >> > >> #define PRINT_ELEMS(fdt, ...) print_elems(fdt, __VA_NARG__(__VA_ARGS__), __VA_ARGS__) > > > > Um.. that might work, but it's ludicrously complicated. If we're > > prepared to use the gcc statement expression extension and we're just > > going to abort on errors like findnode_nofail, it can be done much > > more easily using c99 variadic macros: > > > > #define setprop_ints(fdt, path, prop, ...) \ > > do { \ > > uint32_t tmp[] = {__VA_ARGS__}; \ > > > > if (fdt_setprop(findnode_nofail(fdt, path), prop, \ > > tmp, sizeof(tmp)) != 0) { \ > > /* error message */ \ > > abort(); \ > > } \ > > } while (0) > > Hrm. But here we'd be overloading the name space, no? If anyone > passes in tmp[3] as parameter to setprop_ints, it would conflict > with the internal variable tmp, right? Standard macro problem. So, call it _tmp, whatever. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson