On 2013-02-07 at 13:46 -0800, Todd Lyons wrote: > I ended up going a different route. I don't like making this function > global. I don't know enough of the history of the logging subsystem > (or exim for that matter) and I don't want to reduce security in some > esoteric way.
Just remove the static. > See any issues with this? To be honest, I feel the security concerns > are the same with this wrapper function since it's just a pass-thru. > I'm testing the code now. Yes. In fact, the wrapper adds to the stack and is very slightly slower, unless just optimised away by the compiler toolchain. The fact that the latter can happen should suggest that there's no significant security difference. A symbol being private or exposed should never really be a security concern; it might affect dlopen() results if a symbol would otherwise come from a module, perhaps? And that's stretching to find a contrived example. I mean, sure, once it's not static, a local_scan.c function can include an extern declaration and get access to the code, but those functions are running in the same address-space and could just duplicate the functionality anyway. Functions are static because the non-static functions are internal API and it's cleaner to keep implementation details private. Once you have a need for something as non-static, remove the static. The only exception is in dynamically loaded modules, where you need to think carefully about how the symbol is going to be _used_ and if we need to restructure a table of exports or somesuch. -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
