All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: GNU C Library <libc-alpha@sourceware.org>,
	Ivan Zuboff <anotherdiskmag@gmail.com>
Cc: linux-man@vger.kernel.org, mtk.manpages@gmail.com
Subject: Re: SA_ONSTACK: man page and glibc reference manual in conflict
Date: Mon, 31 Jan 2022 22:23:26 +0100	[thread overview]
Message-ID: <5cfb23b8-de77-3eec-92d0-da29fededf4c@gmail.com> (raw)
In-Reply-To: <CAL-cVegvPvu6kZgn5x=6gimzuSTfCErKzTL+8+1UgQxM3fiNQQ@mail.gmail.com>

Hi all,

On 1/31/22 10:29, Ivan Zuboff wrote:
> Hello!
> 
> Man page says:
> SA_ONSTACK
>               Call the signal handler on an alternate signal stack
>               provided by sigaltstack(2).  *If an alternate stack is not
>               available, the default stack will be used.*  This flag is
>               meaningful only when establishing a signal handler.
> https://man7.org/linux/man-pages/man2/sigaction.2.html
> 
> glibc reference manual says:
> Macro: int SA_ONSTACK
> If this flag is set for a particular signal number, the system uses
> the signal stack when delivering that kind of signal. See Signal
> Stack. *If a signal with this flag arrives and you have not set a
> signal stack, the system terminates the program with SIGILL.*
> https://www.gnu.org/software/libc/manual/html_node/Flags-for-Sigaction.html
> 
> As far as I understand, statements in *stars* are in conflict. glibc
> documentation says that "While the glibc manual remains the canonical
> source for API descriptions, the man-pages are an excellent
> reference.", so I decided to mail you supposing that man page is
> incorrect in this regard.
> https://www.gnu.org/software/libc/documentation.html
> 
> Please correct me if I'm wrong. Also, sorry for my bad English, this
> is not my native language.
> 
> Best regards,
> Ivan

I received this bug report on linux-man@.  The report is about a text
that predates git in the man-pages.  Could you please confirm the bug,
and check if anything else needs to be fixed too?

Thanks,

Alex

Ivan:  Thanks for the report!  In non-trivial cases such as this one,
it's useful to CC the glibc mailing list, since they probably know more
than I about details such as this one. ;)

Cheers,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

  reply	other threads:[~2022-01-31 21:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31  9:29 SA_ONSTACK: man page and glibc reference manual in conflict Ivan Zuboff
2022-01-31 21:23 ` Alejandro Colomar (man-pages) [this message]
2022-01-31 21:53   ` Florian Weimer

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=5cfb23b8-de77-3eec-92d0-da29fededf4c@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=anotherdiskmag@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.