Mailing List Archive

I quite often find myself writing nontrivially-sized chunks of C code
that construct optree fragments. If the optree contains only base OPs,
UNOPs, BINOPs or LOGOPs then you can usually write the entire tree in a
big nested shape of C code. But not so for LISTOPs, because of the
annoying inconvenience of having to go construct a plain OP_LIST and
then op_convert_list() it to the target type. This results in noisy
code that's hard to read the intent of; e.g.:

OP *checkop = newLISTOP(OP_LIST, 0, NULL, NULL);
checkop = op_append_elem(OP_LIST, checkop,
newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkobj)));
checkop = op_append_elem(OP_LIST, checkop,
newSLUGOP(1));
checkop = op_append_elem(OP_LIST, checkop,
newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkcv)));

checkop = op_convert_list(OP_ENTERSUB, G_VOID, checkop);

I propose that now we have C99 and we can use __VA_LIST__ in macros, we
could neaten this up enormously into:

OP *checkop = newLISTOPn(OP_ENTERSUB, G_VOID,
newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkobj)),
newSLUGOP(1),
newSVOP(OP_CONST, 0, SvREFCNT_inc(data->checkcv)));

This basically requires making a valist-taking function, and wrapping
it in a macro thus:

#define newLISTOPn(type, flags, ...) \
Perl_newLISTOPn(aTHX_ type, flags, __VA_ARGS__, NULL)

Since we already have macros that use __VA_ARGS__, I don't imagine this
will be problematic. I expect that, as well as providing a handy
shortcut for XS modules and the like, there's probably quite a few
places in core code that could be similarly neatened by it.

Before I write up a quick little PR to add this, can anyone spot a
reason why not to?

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/