public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: "Tomáš Golembiovský" <tgolembi@redhat.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: Alejandro Colomar <alx@kernel.org>, linux-man@vger.kernel.org
Subject: Re: [PATCH v2] abort: clarify consequences of calling abort
Date: Wed, 12 Jul 2023 10:11:10 +0200	[thread overview]
Message-ID: <ZK5gHuquXody9x2b@cremorrah> (raw)
In-Reply-To: <20230710152150.b7lwmzwmuqjxxsiv@illithid>

Hi,

On Mon, Jul 10, 2023 at 10:21:50AM -0500, G. Branden Robinson wrote:
> Hi Tomáš,
> 
> At 2023-07-10T15:59:28+0200, Tomáš Golembiovský wrote:
> [...]
> > Clarify the status reported by wait*() functions. The requirement
> > comes from POSIX specification.
> [...]
> > +The status made available to
> > +.BR wait "(2), " waitid "(2), or " waitpid (2)
> > +by
> > +.BR abort ()
> > +shall be that of a process terminated by the
> > +.BR SIGABRT
> > +signal.
> [...]
> 
> I believe Alex's preference in the Linux man-pages project is to
> document what is actually implemented, not to repeat normative language
> (paraphrased or not) from the POSIX standard.

Yeah, I don't feel strong about it and I have my doubts if mentioning is
useful anyway. It should be obvious from the fact that abort() raises
SIABGRT. I will drop that sentence. 

> 
> So glibc should be tested to verify the behavior it actually exhibits,
> and the language above then updated to describe that, noting any
> deviation from POSIX's prescription.

As a side note, in the normal situation glibc does what it should.
However, in the unlikely situation that raise() fails unexpectedly,
abort() tries to terminate the process with other means or loops for
ever if everything else fails to satisfy the condition that abort()
should never return.

    Tomas

> 
> The same can, optionally, be done for other libcs like musl.
> 
> Alex, please correct me if I'm mistaken.
> 
> Regards,
> Branden



  reply	other threads:[~2023-07-12  8:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-10 13:59 [PATCH v2] abort: clarify consequences of calling abort Tomáš Golembiovský
2023-07-10 15:21 ` G. Branden Robinson
2023-07-12  8:11   ` Tomáš Golembiovský [this message]
2023-07-12 10:45   ` Stefan Puiu
2023-07-15 15:44     ` Alejandro Colomar

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=ZK5gHuquXody9x2b@cremorrah \
    --to=tgolembi@redhat.com \
    --cc=alx@kernel.org \
    --cc=g.branden.robinson@gmail.com \
    --cc=linux-man@vger.kernel.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