Date: Sat, 22 Feb 2003 11:26:54 -0800 (PST) From: John Polstra <jdp@polstra.com> To: hackers@freebsd.org Cc: tlambert2@mindspring.com Subject: Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop Message-ID: <200302221926.h1MJQsgw022805@vashon.polstra.com> In-Reply-To: <3E5437CB.DC14EC42@mindspring.com> References: <20030219134131.T70370-100000@logout.sh.cvut.cz> <3E5437CB.DC14EC42@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <3E5437CB.DC14EC42@mindspring.com>,
Terry Lambert <tlambert2@mindspring.com> wrote:
> Vaclav Haisman wrote:
> > Besides, this doesn't explain anything. I see I haven't asked any question in
> > my previous post. So, why does FreeBSD behave different?
>
> Because POSIX mandates that it do so?
>
> man 3 signal tells us:
>
> The handled signal is unblocked when the function returns and the process
> continues from where it left off when the signal occurred. Unlike previ-
> ous signal facilities, the handler func() remains installed after a sig-
> nal has been delivered.
POSIX mandates no such thing. You missed the part of the POSIX spec
that says:
The behavior of a process is undefined after it returns normally
from a signal-catching function for a SIGFPE, SIGILL, SIGSEGV,
or SIGBUS signal that was not generated by the kill() function,
the sigqueue() function, or the raise() function as defined by
the C Standard.
It's in ANSI/IEEE Std 1003.1 section 3.3.1.3.
POSIX permits the FreeBSD behavior but does not mandate it.
John
--
John Polstra
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302221926.h1MJQsgw022805>