Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sourceware.org, gdb-patches@sources.redhat.com
Subject: Re: [linux] Always ignore restart/cancellation signals
Date: Fri, 09 Dec 2005 20:52:00 -0000	[thread overview]
Message-ID: <20051209143451.GA11917@nevyn.them.org> (raw)
In-Reply-To: <uzmnajxuh.fsf@gnu.org>

On Fri, Dec 09, 2005 at 01:47:50PM +0200, Eli Zaretskii wrote:
> There's no need to, IMHO.  I think Jim was wrong: symbols starting
> with __ are indeed reserved for the implementation, but the meaning of
> that reservation is that user code should not _define_ such symbols,
> not that it must not use them.  In effect, this rule sets up a
> namespace that the library implementation can use without risking that
> it steps on the feet of user code.  But if we don't define any symbols
> that begin with __, we are safe accessing them, I think.

OK.

> I have no idea why the above comment from bits/signum.h was written.
> I think it is wrong and the glibc maintainers should be asked to
> either remove it or explain why they think these symbols should not be
> used at user level.

The comment is actually correct - for the vast majority of users of the
header.  I've long ago accepted that it's GDB's business to poke around
in the implementation :-)

The problem is that an application may want to register handlers for "a
few" realtime signals.  It seems common to count up from SIGRTMIN, so
SIGRTMIN is made a runtime constant that skips those signals belonging
to the implementation.  If you use the constant in the header for
anything, the implementation reserves the right to kick you when you're
down.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


WARNING: multiple messages have this Message-ID
From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sourceware.org, gdb-patches@sources.redhat.com
Subject: Re: [linux] Always ignore restart/cancellation signals
Date: Fri, 09 Dec 2005 20:49:00 -0000	[thread overview]
Message-ID: <20051209143451.GA11917@nevyn.them.org> (raw)
Message-ID: <20051209204900.ZdxWBqWZNJPoz63HM9NvLsGYzsvdy89QN9EypYKBCEg@z> (raw)
In-Reply-To: <uzmnajxuh.fsf@gnu.org>

On Fri, Dec 09, 2005 at 01:47:50PM +0200, Eli Zaretskii wrote:
> There's no need to, IMHO.  I think Jim was wrong: symbols starting
> with __ are indeed reserved for the implementation, but the meaning of
> that reservation is that user code should not _define_ such symbols,
> not that it must not use them.  In effect, this rule sets up a
> namespace that the library implementation can use without risking that
> it steps on the feet of user code.  But if we don't define any symbols
> that begin with __, we are safe accessing them, I think.

OK.

> I have no idea why the above comment from bits/signum.h was written.
> I think it is wrong and the glibc maintainers should be asked to
> either remove it or explain why they think these symbols should not be
> used at user level.

The comment is actually correct - for the vast majority of users of the
header.  I've long ago accepted that it's GDB's business to poke around
in the implementation :-)

The problem is that an application may want to register handlers for "a
few" realtime signals.  It seems common to count up from SIGRTMIN, so
SIGRTMIN is made a runtime constant that skips those signals belonging
to the implementation.  If you use the constant in the header for
anything, the implementation reserves the right to kick you when you're
down.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


  reply	other threads:[~2005-12-09 14:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-08 21:10 Daniel Jacobowitz
2005-12-09 10:39 ` Mark Kettenis
2005-12-09 11:09   ` Kevin Buettner
2005-12-09 11:26     ` Daniel Jacobowitz
2005-12-09 11:48       ` Kevin Buettner
2005-12-09 14:46       ` Eli Zaretskii
2005-12-09 20:52         ` Daniel Jacobowitz [this message]
2005-12-09 20:49           ` Daniel Jacobowitz
2005-12-09 21:55           ` Eli Zaretskii
2005-12-09 23:13             ` Daniel Jacobowitz
2005-12-10  1:20               ` Eli Zaretskii
2005-12-10  1:29                 ` Daniel Jacobowitz
2005-12-10  1:29                   ` Eli Zaretskii
2005-12-10  1:49                   ` Mark Kettenis
2005-12-10  2:10                     ` Daniel Jacobowitz
2005-12-10  4:47                       ` Mark Kettenis
2005-12-10  1:34         ` Jim Blandy
2005-12-11 17:26           ` Eli Zaretskii
2006-02-20 17:01 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051209143451.GA11917@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox