Re: [0/2] Inspect extra signal information

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 13 January 2009 18:41:28, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Tue, 13 Jan 2009 11:05:34 +0000
> > Cc: Mark Kettenis <mark.kettenis@xs4all.nl>
> > 
> > On Monday 12 January 2009 23:24:16, Mark Kettenis wrote:
> > 
> > > One thing I wonder about is whether it really is a good idea to is the
> > > obfuscated typenames like __uid_t instead of a straight uid_t.  I
> > > realize that is the way the type is defined in headers, but in GDB we
> > > don't really have to worry about namespace pollution.
> > 
> > I don't really have much of an opinion here.  I didn't think of a reason
> > to be different, so I just cloned the types from glibc's headers.  I
> > can change that if you think it's important.
> 
> I happen to agree with Mark.  Not only we don't need to use symbols
> with leading underscores, it's actually forbidden by the C Standard
> (AFAIK).  Such names are "reserved for the implementation" of the C
> language, which we aren't.
> 

I don't think that argument fits this case, because, well, this
is really a kernel data type, which can use it's own rules.  There's no
way for this $_siginfo type to collide with anything in the user code.  Also, these
are also the types you'd see if I wasn't synthesizing it, but using the debug
info instead, in case it is available  --- I was actually doing that in a previous
version of the patch, and synthesized the type only as a fallback, but, then considered
that if we're synthesizing sometimes, might as well make it simpler and
always synthesize -- less cases, less bugs, less maintenance.

Do you not agree in the light of this perpective?

I can change it, but I just want to make sure we're seeing
the whole picture.

-- 
Pedro Alves