Re: [boost] [log] Boost.Log Formal Review

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:
>>>>> maybe
>>>>>
>>>>> #if defined (LOG_NTRACE)
>>>>> #define LOG_TRACE(logger, stream) if (true); else logger
>>>>> #else
>>>>> #define LOG_TRACE(logger, stream) BOOST_LOG_SEV(logger, trace)<<    stream;
>>>>> #endif
>>>>>
>>>>> 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, 
though).

So the safest and most efficient way to achieve that is to wipe out the 
logging statement on the preprocessing stage.