what exactly cstyle isn't happy about here: pastebin.com/HC8Sr30G? "t.h: 1: missing space before left brace"

adding whitespace before brace makes it say "whitespace after left paren"

yuripv: I think you want a do {} while (0) guard there?

yuripv: like github.com/illumos/illumos-gate/blo…mon/fs/zfs/sys/arc_impl.h#L346-L352

without the _NOTE(CONSTCOND) obviously because we don't note.h anymore

the macro is used then as "val = MACRO(arg);" and that fails with "expected expression before 'do'"

not my code, and it builds and works fine as it is, it's just cstyle that isn't happy

macros that return things feel somewhat unsavoury

unless they're just expressions

inline function perhaps?

If it has to be a macro I don't know what the parens around the braces buy you

so I would try removing them?

expected expression before '{' token

can you maybe show me more of the code

so inline functions could be an answer here

I think inline functions are probably in general better than macros for a variety of reasons though yeah

(more contained, more type safe, less accidental double-evaluation of arguments, etc)

as an example

ah

We're definitely into a corner of C I am not comfortable in haha

that really doesn't seem like it could possibly be an expression

also.. __typeof yeesh

and __typeof for type of return value would not allow for inline function?

I guess yeah

I suppose you can always /*CSTYLED*/ it!

also, this must surely be in whacky third party code?

It wouldn't be the first third party code to end up on github.com/illumos/illumos-gate/blob/master/exception_lists/cstyle

if we're planning to update it in future without restyling it for example

is it from some SNMP thing?

yes, 3d party code that i'm just trying to build and look a bit better

yep

experimenting with begemot snmp implementation instead of unwieldy net-snmp

if it's 3rd party it would not be the end of the world for it to be cstyle exempt on some level, I suspect. Probably someone else should weigh in to tell me I'm not crazy

thanks Joshua

you're welcome!

hope the experiment goes w{ll

*well

tsoome ping

I think gcc finds that to be an expression

I'm not sure if that's an extension

isn't that the same kind of weird trick we pull for strdupa (in spirit, if not in fact?)

yeah, we wrap it in __extension__() and damn the indentation

see string.h

I'd prefer /*CSTYLED*/ to just ignoring taste

it's meant to make your code "fit in", not to make your code fucking ugly because a perl script says so

if that helps guide you :)

yes, ({...}) are gcc "statement expressions", which I doubt cstyle ever knew about: gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

they're proposed for a version of the C standard after C23, but for now I think are just a gcc extension that some other compilers (including Studio 12.6 I believe) now also support