Allow building parts of processor code on Win32

I want to use some of the processor code for unit tests on Win32, so this fixes
compilation of just enough of it with VC++ for me to do what I want.

[Mark Mentovai]

LGTM

http://breakpad.appspot.com/250001/diff/1/3
File src/processor/logging.cc (right):

http://breakpad.appspot.com/250001/diff/1/3#newcode47
Line 47: #ifdef _WIN32
Outside of the namespace, please.

http://breakpad.appspot.com/250001/diff/1/4
File src/processor/logging.h (right):

http://breakpad.appspot.com/250001/diff/1/4#newcode71
Line 71: // These are defined in Microsoft headers.
A little scary.

[Ted Mielczarek]

http://breakpad.appspot.com/250001/diff/1/4
File src/processor/logging.h (right):

http://breakpad.appspot.com/250001/diff/1/4#newcode71
Line 71: // These are defined in Microsoft headers.
On 2011/01/11 19:44:54, Mark Mentovai wrote:
> A little scary.

I agree. Would you prefer I used #pragma push_macro / pop_macro?
http://msdn.microsoft.com/en-us/library/2bs04eza%28v=vs.71%29.aspx

I wrote this patch a while ago, maybe I forgot about its existence at the time.

[Mark Mentovai]

http://breakpad.appspot.com/250001/diff/1/4
File src/processor/logging.h (right):

http://breakpad.appspot.com/250001/diff/1/4#newcode71
Line 71: // These are defined in Microsoft headers.
Ted Mielczarek wrote:
> I agree. Would you prefer I used #pragma push_macro / pop_macro?
> http://msdn.microsoft.com/en-us/library/2bs04eza%28v=vs.71%29.aspx

I’d prefer not having a collision at all, but that’s not really an option here.

Popping the old value of the macro still sucks when other Breakpad code needs to
use SEVERITY_ERROR or ERROR. Maybe it even sucks more.

I just wanted to point out the disgust in case it was maybe possible to avoid
the Windows header that clashes altogether.

[Ted Mielczarek]

http://breakpad.appspot.com/250001/diff/1/4
File src/processor/logging.h (right):

http://breakpad.appspot.com/250001/diff/1/4#newcode71
Line 71: // These are defined in Microsoft headers.
On 2011/01/11 19:54:51, Mark Mentovai wrote:
> I just wanted to point out the disgust in case it was maybe possible to avoid
> the Windows header that clashes altogether.

There are no collisions in the processor code, since it doesn't include
windows.h. I believe I hit this when adding the headers to an existing Windows
unittest in a patch that's sitting in my patch queue, probably here:
http://hg.mozilla.org/users/tmielczarek_mozilla.com/breakpad-mq/file/e6f3de86...

Since it follows the style guide and includes system headers first, it runs into
this problem.