[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Jul 2016 11:31:40 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Jorge Almeida <jjalmeida@...il.com>
Subject: Re: abort() PID 1
* Jorge Almeida <jjalmeida@...il.com> [2016-07-04 01:09:32 -0700]:
> What I thought I understood:
>
> - the kernel will not deliver any signal to process 1, unless a signal
> handler for that particular signal has been installed
>
not all signals behave that way.
> -if process 1 calls abort() (regardless of what purpose that would fill), then:
>
> - if a handler was setup, it should be done whatever the handler does
>
> - if a handler was not setup, nothing should happen (as in:
> process didn't receive any signal at all)
>
this is raise(SIGABRT), abort is different.
>
> What the standards say:
>
> (http://pubs.opengroup.org/onlinepubs/9699919799/)
>
> "The SIGABRT signal shall be sent to the calling process as if by
> means of raise() with the argument SIGABRT."
>
it also says
"The abort() function shall cause abnormal process termination
to occur, unless the signal SIGABRT is being caught and the
signal handler does not return."
and
"The abort() function shall not return."
(in c11 abort is _Noreturn and returning from such a function
is undefined behaviour).
> DISCLAIMER: well-meaning amateur here. I'm pretty sure I understood
> what I quoted, but I'm assuming the standard doesn't have any
> self-inconsistencies.
there is no inconsistency.
abort should raise(SIGABRT) and it should terminate the process.
(normally there should be an abort syscall provided by the kernel,
but linux does not have it.)
> So, can one trust the man pages?
not always, use the standard for standard interfaces.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
