Fix linux compile errors for some systems.

Fix linux compile errors for some systems.

[jakerr]

https://breakpad.appspot.com/460002/diff/1/src/client/linux/crash_generation/...
File src/client/linux/crash_generation/client_info.h (right):

https://breakpad.appspot.com/460002/diff/1/src/client/linux/crash_generation/...
src/client/linux/crash_generation/client_info.h:40: :
crash_server_(crash_server),
This looked like a typo.

https://breakpad.appspot.com/460002/diff/1/src/google_breakpad/common/minidum...
File src/google_breakpad/common/minidump_exception_linux.h (right):

https://breakpad.appspot.com/460002/diff/1/src/google_breakpad/common/minidum...
src/google_breakpad/common/minidump_exception_linux.h:85: of signals defined in
signum. */
Using -1 caused compilation errors for us since this is used as value of
MDException struct's "exception_code" which is u_int32_t.

Ted, would a sentinel of 66 be okay instead?

[Ted Mielczarek]

https://breakpad.appspot.com/460002/diff/1/src/client/linux/crash_generation/...
File src/client/linux/crash_generation/client_info.h (right):

https://breakpad.appspot.com/460002/diff/1/src/client/linux/crash_generation/...
src/client/linux/crash_generation/client_info.h:40: :
crash_server_(crash_server),
On 2012/09/26 00:23:35, jakerr wrote:
> This looked like a typo.

Certainly looks like it. I think we just don't happen to use this member
anywhere.

https://breakpad.appspot.com/460002/diff/1/src/client/linux/handler/exception...
File src/client/linux/handler/exception_handler_unittest.cc (right):

https://breakpad.appspot.com/460002/diff/1/src/client/linux/handler/exception...
src/client/linux/handler/exception_handler_unittest.cc:64: string file = dir +
"/exception-handler-unittest.XXXXXX";
I noticed these std::strings had snuck in in a previous patch but I had too many
other things to deal with to clean them up.

https://breakpad.appspot.com/460002/diff/1/src/google_breakpad/common/minidum...
File src/google_breakpad/common/minidump_exception_linux.h (right):

https://breakpad.appspot.com/460002/diff/1/src/google_breakpad/common/minidum...
src/google_breakpad/common/minidump_exception_linux.h:85: of signals defined in
signum. */
On 2012/09/26 00:23:35, jakerr wrote:
> Using -1 caused compilation errors for us since this is used as value of
> MDException struct's "exception_code" which is u_int32_t.
> 
> Ted, would a sentinel of 66 be okay instead?

Can you just change this to 0xFFFFFFFF to make it compile? I really like the
"totally not a signal" value in there (also it means I don't have to worry about
updating things to match).

[jakerr]

On 2012/09/26 00:31:47, Ted Mielczarek wrote:
>
https://breakpad.appspot.com/460002/diff/1/src/client/linux/crash_generation/...
> File src/client/linux/crash_generation/client_info.h (right):
> 
>
https://breakpad.appspot.com/460002/diff/1/src/client/linux/crash_generation/...
> src/client/linux/crash_generation/client_info.h:40: :
> crash_server_(crash_server),
> On 2012/09/26 00:23:35, jakerr wrote:
> > This looked like a typo.
> 
> Certainly looks like it. I think we just don't happen to use this member
> anywhere.
> 
>
https://breakpad.appspot.com/460002/diff/1/src/client/linux/handler/exception...
> File src/client/linux/handler/exception_handler_unittest.cc (right):
> 
>
https://breakpad.appspot.com/460002/diff/1/src/client/linux/handler/exception...
> src/client/linux/handler/exception_handler_unittest.cc:64: string file = dir +
> "/exception-handler-unittest.XXXXXX";
> I noticed these std::strings had snuck in in a previous patch but I had too
many
> other things to deal with to clean them up.
> 
>
https://breakpad.appspot.com/460002/diff/1/src/google_breakpad/common/minidum...
> File src/google_breakpad/common/minidump_exception_linux.h (right):
> 
>
https://breakpad.appspot.com/460002/diff/1/src/google_breakpad/common/minidum...
> src/google_breakpad/common/minidump_exception_linux.h:85: of signals defined
in
> signum. */
> On 2012/09/26 00:23:35, jakerr wrote:
> > Using -1 caused compilation errors for us since this is used as value of
> > MDException struct's "exception_code" which is u_int32_t.
> > 
> > Ted, would a sentinel of 66 be okay instead?
> 
> Can you just change this to 0xFFFFFFFF to make it compile? I really like the
> "totally not a signal" value in there (also it means I don't have to worry
about
> updating things to match).

Yeah good point, and works for us. Thanks.

[jakerr]

On 2012/09/26 00:46:45, jakerr wrote:
> On 2012/09/26 00:31:47, Ted Mielczarek wrote:
> >
>
https://breakpad.appspot.com/460002/diff/1/src/client/linux/crash_generation/...
> > File src/client/linux/crash_generation/client_info.h (right):
> > 
> >
>
https://breakpad.appspot.com/460002/diff/1/src/client/linux/crash_generation/...
> > src/client/linux/crash_generation/client_info.h:40: :
> > crash_server_(crash_server),
> > On 2012/09/26 00:23:35, jakerr wrote:
> > > This looked like a typo.
> > 
> > Certainly looks like it. I think we just don't happen to use this member
> > anywhere.
> > 
> >
>
https://breakpad.appspot.com/460002/diff/1/src/client/linux/handler/exception...
> > File src/client/linux/handler/exception_handler_unittest.cc (right):
> > 
> >
>
https://breakpad.appspot.com/460002/diff/1/src/client/linux/handler/exception...
> > src/client/linux/handler/exception_handler_unittest.cc:64: string file = dir
+
> > "/exception-handler-unittest.XXXXXX";
> > I noticed these std::strings had snuck in in a previous patch but I had too
> many
> > other things to deal with to clean them up.
> > 
> >
>
https://breakpad.appspot.com/460002/diff/1/src/google_breakpad/common/minidum...
> > File src/google_breakpad/common/minidump_exception_linux.h (right):
> > 
> >
>
https://breakpad.appspot.com/460002/diff/1/src/google_breakpad/common/minidum...
> > src/google_breakpad/common/minidump_exception_linux.h:85: of signals defined
> in
> > signum. */
> > On 2012/09/26 00:23:35, jakerr wrote:
> > > Using -1 caused compilation errors for us since this is used as value of
> > > MDException struct's "exception_code" which is u_int32_t.
> > > 
> > > Ted, would a sentinel of 66 be okay instead?
> > 
> > Can you just change this to 0xFFFFFFFF to make it compile? I really like the
> > "totally not a signal" value in there (also it means I don't have to worry
> about
> > updating things to match).
> 
> Yeah good point, and works for us. Thanks.

This is ready to go in if everyone's happy.

[Ted Mielczarek]

LGTM

[qsr]

Commited as revision: 1055.

Jake, could you close the CL please.

[jakerr]

Done,
Thank you.


On Tue, Oct 2, 2012 at 8:02 PM, <qsr@chromium.org> wrote:

> Commited as revision: 1055.
>
> Jake, could you close the CL please.
>
> https://breakpad.appspot.com/**460002/<https://breakpad.appspot.com/460002/>
>