04:26:20 <yuripv> what exactly cstyle isn't happy about here: https://pastebin.com/HC8Sr30G? "t.h: 1: missing space before left brace"
04:27:39 <yuripv> adding whitespace before brace makes it say "whitespace after left paren"
05:10:31 <jclulow> yuripv: I think you want a do {} while (0) guard there?
05:13:15 <jclulow> yuripv: like https://github.com/illumos/illumos-gate/blob/17c4dadf772c2bfb28130f501dc6e1f46f8b1250/usr/src/uts/common/fs/zfs/sys/arc_impl.h#L346-L352
05:13:32 <jclulow> without the _NOTE(CONSTCOND) obviously because we don't note.h anymore
05:21:28 <yuripv> the macro is used then as "val = MACRO(arg);" and that fails with "expected expression before 'do'"
05:21:44 <yuripv> not my code, and it builds and works fine as it is, it's just cstyle that isn't happy
05:23:32 <jclulow> macros that return things feel somewhat unsavoury
05:23:39 <jclulow> unless they're just expressions
05:24:32 <jclulow> inline function perhaps?
05:27:03 <jclulow> If it has to be a macro I don't know what the parens around the braces buy you
05:27:10 <jclulow> so I would try removing them?
05:28:06 <yuripv> expected expression before '{' token
05:28:26 <jclulow> can you maybe show me more of the code
05:28:28 <yuripv> so inline functions could be an answer here
05:28:54 <jclulow> I think inline functions are probably in general better than macros for a variety of reasons though yeah
05:29:17 <jclulow> (more contained, more type safe, less accidental double-evaluation of arguments, etc)
05:29:33 <yuripv> https://pastebin.com/9cVycc6S
05:29:39 <yuripv> as an example
05:29:44 <jclulow> ah
05:31:03 <jclulow> We're definitely into a corner of C I am not comfortable in haha
05:31:12 <jclulow> that really doesn't seem like it could possibly be an expression
05:32:16 <jclulow> also.. __typeof yeesh
05:32:20 <yuripv> and __typeof for type of return value would not allow for inline function?
05:32:27 <jclulow> I guess yeah
05:32:44 <jclulow> I suppose you can always /*CSTYLED*/ it!
05:33:46 <jclulow> also, this must surely be in whacky third party code?
05:34:11 <jclulow> It wouldn't be the first third party code to end up on https://github.com/illumos/illumos-gate/blob/master/exception_lists/cstyle
05:34:22 <jclulow> if we're planning to update it in future without restyling it for example
05:35:02 <jclulow> is it from some SNMP thing?
05:35:06 <yuripv> yes, 3d party code that i'm just trying to build and look a bit better
05:35:08 <yuripv> yep
05:35:48 <yuripv> experimenting with begemot snmp implementation instead of unwieldy net-snmp
05:35:52 <jclulow> 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
05:37:15 <yuripv> thanks Joshua
05:37:26 <jclulow> you're welcome!
05:37:32 <jclulow> hope the experiment goes w{ll
05:37:34 <jclulow> *well
12:21:57 <igork> tsoome ping
20:35:08 <richlowe> I think gcc finds that to be an expression
20:35:14 <richlowe> I'm not sure if that's an extension
20:35:57 <richlowe> isn't that the same kind of weird trick we pull for strdupa (in spirit, if not in fact?)
20:36:31 <richlowe> yeah, we wrap it in __extension__() and damn the indentation
20:36:34 <richlowe> see string.h
20:37:02 <richlowe> I'd prefer /*CSTYLED*/ to just ignoring taste
20:37:38 <richlowe> it's meant to make your code "fit in", not to make your code fucking ugly because a perl script says so
20:37:47 <richlowe> if that helps guide you :)
20:42:02 <alanc> yes, ({...}) are gcc "statement expressions", which I doubt cstyle ever knew about: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
20:45:28 <alanc> 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