Re: [0/2] Inspect extra signal information

Pedro Alves
2009-01-13T18:50:31Z

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