From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scbam-00030w-1Y for qemu-devel@nongnu.org; Thu, 07 Jun 2012 08:13:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Scbaj-0005dT-VG for qemu-devel@nongnu.org; Thu, 07 Jun 2012 08:13:31 -0400 Date: Thu, 7 Jun 2012 22:13:18 +1000 From: David Gibson Message-ID: <20120607121318.GF6614@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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) -- 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