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