Hi again,
On Wed, Jul 03, 2019 at 02:47:59PM +0200, Marc Gonzalez wrote:
> On 02/07/2019 11:51, Jonathan Neuschäfer wrote:
> > On Mon, Jul 01, 2019 at 01:44:09PM +0200, Marc Gonzalez wrote:
[...]
> >> static const struct dvb_frontend_ops si2168_ops;
> >>
> >> +#define CMD_SETUP(cmd, __args, __rlen) do { \
> >> + int wlen = sizeof(__args) - 1; \
> >> + memcpy(cmd.args, __args, wlen); \
> >> + cmd.wlen = wlen; cmd.rlen = __rlen; \
> >> +} while (0)
> >
> > It would be nice for casual readers to have a little comment here, that
> > explains (briefly) what this macro does, and what the arguments mean,
> > and their types.
>
> Just a bit of background.
>
> A macro is required /at some point/ because arrays "decay" into pointers
> when used as function arguments.
*nod*
[ I should have been more specific: By "here" I meant at that spot in
the code, and by casual readers I mostly meant casual readers of the
code once it's merged. ]
> Come to think of it, I'm really not a fan of "large" macro functions.
> I'll outline a different option in v2.
The v2 approach looks nicer to me, thanks.
> > Why cmd rather than __cmd? This seems inconsistent.
>
> Note: I hate using underscores in macro argument names, but they clashed
> with the struct field names. There was no such clash for 'cmd'.
Hmm, ok.
> > The wlen local variable can be avoided by a bit of suffling:
> >
> > #define CMD_SETUP(cmd, __args, __rlen) do { \
> > cmd.rlen = __rlen; \
> > cmd.wlen = sizeof(__args) - 1; \
> > memcpy(cmd.args, __args, cmd.wlen); \
> > } while (0)
>
> Do you think it is important to avoid a local variable?
Not exactly important, but wlen would be another name that can collide
with the name spaces of the functions where the macro is used and
trigger -Wshadow.
Greetings,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
