Auteur: Phil Pennock Date: À: Todd Lyons CC: exim-dev Sujet: Re: [exim-dev] Using log_create() from src/src/log.c
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.