dhcpcd-discuss

Hi Sergey

On 10/02/2020 13:46, Sergey Nikiforov wrote:
> PoC patch is attached (not so small because dhcp.c required a lot of changes). 
> It is not complete and is not compilable, I have implemented only "loginfox" and 
> fixed only dhcp.c and ipv6.c.

+/* It is a macro to prevent taking address of it so __FILE__/__LINE__ etc
+ * can easily be added */
+#define loginfox(fmt, ...) loginfox_func(fmt, ##__VA_ARGS__)

##__VA_ARGS__ is gcc specific
__VA_OPT__ is standards compliant

+#define loginfox(fmt, ...) loginfox_func(fmt __VA_OPT__(,) __VA_ARGS__)
But only gcc-8 and clang-6 support that.
It was only 5 days ago where a user supplied a patch for building on old systems 
without O_CLOEXEC and SOCK_CLOEXEC defined!

However, we can workaround it like so:
+#define loginfox(fmt, ...) loginfox_func(__VA_ARGS__)

This forces the format string into va_args. Luckily in all cases the format 
string IS the last named parameter so this should be safe. As __VA_ARGS__ is in 
c99 and we require c99 this should be fine.
Might be worth adding a note about that in logerr.h to explain it incase we 
forget :)

Lastly, I dislike just adding _func to the function name. Just separating with 
an underscore would be better I think:
+#define loginfox(fmt, ...) log_infox(__VA_ARGS__)

> BTW code w/o indirect function calls is faster, especially if retpolines are 
used..

Speed isn't really a concern.
The only concern I have left is that we then need to expose syslog.h and one of 
the goals of logerr was to hide that away.
Still I don't see anything cleaner just yet.

I do have another question though .... how would you then hook into this?
At a guess you then have your own stubs which take __FILE__ and __LINE__, 
prepend that into and then call out to the actual functions or another?

Roy