Subject: Re: [boost] [log] Boost.Log Formal Review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-18 13:27:26
On 03/18/2010 01:07 AM, vicente.botet wrote:
>>>>> #if defined (LOG_NTRACE)
>>>>> #define LOG_TRACE(logger, stream) if (true); else logger
>>>>> #define LOG_TRACE(logger, stream) BOOST_LOG_SEV(logger, trace)<< stream;
>>>>> I would like all the BOOST_LOG logger macros works this way.
>>>> That still leaves the streaming statements compiled. Although they will
>>>> likely be optimized away, this doesn't eliminate the compilation cost
>>>> and does not guarantee that no other traces of logging are left (such as
>>>> string constants or functions).
>>> I think that we need to solve two issues when log is not needed.
>>> 1st : no time at all spent at runtime if log is not needed.
>>> 2nd : reduce the compilation time to a minimum log is not needed.
>>> The first is mandatory, the second is nice to have.
>> One of the first reasons for this request was to remove any trace of
>> logging from the resulting binary (e.g., for security reasons). This
>> includes the things I mentioned.
> You lost me. Could you clarify which security reasons are you talking about?
If resources from logging statements are left in the compiled binary,
they may be used to reverse engineer the application. The point of this
proposal is to leave _absolutely_ nothing from the logging statements in
the final binary.
> I expect the compiler after compiling the expression will not generate any code associated to
> if (true); else .....
The compiler will have to compile it anyway (perhaps, not to generate
actual assembly, but surely to instantiate templates). It may be smart
enough to remove that statement from the final code (most compilers are
that smart). Then the linker may be smart enough to lose the unneeded
string constants and functions that were only involved in the logging
statement. But none of these optimizations are guaranteed to happen. And
that's not overgeneralization, I did work with a compiler that did not
drop unneeded functions from the final binary (not sure about strings,
So the safest and most efficient way to achieve that is to wipe out the
logging statement on the preprocessing stage.