Re: [0/2] Inspect extra signal information

[Eli Zaretskii <eliz@gnu.org>]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Tue, 13 Jan 2009 18:50:01 +0000
> Cc: mark.kettenis@xs4all.nl
> 
> > 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.

The problem is not to clash with GDB code elsewhere, the problem is
the possibility of a clash with the library.  A library implementation
is free to change the symbol it uses for this any time, and use the
__uid_t one for something utterly incompatible.  Since the name begins
with 2 underscores, the library implementation doesn't need to bother
being back-compatible, because such names are off-limits for 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.

Sorry, I don't follow: what do you mean by ``synthesizing''?