qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCH 02/31] dt: add helpers for 2, 3 and


From: David Gibson
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 02/31] dt: add helpers for 2, 3 and 4 cell adds
Date: Sat, 9 Jun 2012 00:15:02 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

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 <stdio.h>
> >> #include <stdarg.h>
> >> 
> >> #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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]