[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a2ba37f2-d498-6958-eb96-5bbfc8b2151c@prevas.dk>
Date: Thu, 10 Aug 2023 10:29:51 +0200
From: Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To: Nick Desaulniers <ndesaulniers@...gle.com>,
Christian König <ckoenig.leichtzumerken@...il.com>
Cc: boris.brezillon@...labora.com, maarten.lankhorst@...ux.intel.com,
mripard@...nel.org, tzimmermann@...e.de, airlied@...il.com,
daniel@...ll.ch, trix@...hat.com, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
naresh.kamboju@...aro.org, dakr@...hat.com
Subject: Re: [PATCH 1/2] drm/exec: use unique instead of local label
On 01/08/2023 22.35, Nick Desaulniers wrote:
> I suspect it's possible to change the indirect goto into a direct goto
> with some further refactoring (macros can take block statements;
Well, with some somewhat subtle restrictions. C99, 6.10.3.11. "The
sequence of preprocessing tokens bounded by the outside-most matching
parentheses forms the list of arguments for the function-like macro. The
individual arguments within the list are separated by comma
preprocessing tokens, but comma preprocessing tokens between matching
inner parentheses do not separate arguments."
cpp doesn't care about the {} tokens when trying to figure out what
constitutes the "block" argument, so if that block contained any comma
outside a () pair, cpp would barf something like
error: macro "foo" passed 3 arguments, but takes just 2
So while the commas inside function calls (and other macro invocations)
are fine, constructs like
int x, y;
or
struct s s = {.a = 3, .b = 4}
would be verboten inside that block.
One way around that is to make block a variadic argument so it just
gobbles up all preprocessor token. Or have the users pass a statement
expression instead of a block.
Rasmus
Powered by blists - more mailing lists