Re: [libvirt] [PATCH 04/11] qemu_security: Kill code duplication

On Thu, Feb 09, 2017 at 09:52:03 +0100, Michal Privoznik wrote: I've hit these a few times. In this case it irritates me that I can't see the ...Initialize function. This does not create functions. This does not create functions. The variables accessed are global and declared without any macro All usage is within one screen. Only opaque function call is to the ...Dispose function. All functions can be viewed with vim -t. The macros are undefined within the single case where it's used. This does not help your example. Don't care, never used ESX. Granted, in tests there are quite a few questionable usages of macros. One of the worst examples is TEST_CHAIN. Tests are usually "fun" to debug. Don't care, never used the dissector really. I'm hitting these regularly, but they are so common that I got used to it and also it's pretty easy to figure out the type name you want to access. Seeing the code in this case would not help that much though. It's far more useful to see the enum or the strings belonging to it. The only option I see here is if we'd generate them into a separate file rather than relying on macros. But as I've said that would not help much since you want to see the strings. This macro uses __LINE__ and __FILE__ stuff so it can't be avoided. Also if you don't enable DTRACE the macro does not expand to anything, which is the default. No I won't fix those just because I rejected your code. Reasoning that something should be allowed because we have prior art is weak. We don't have to make the code uglier than it is.