> > The switch from SIGBUS to SIGSEGV is well motivated.
>
> Is it? I see no mention of it in the commit log for the revision that
> actually implemented the change. David argued on -CURRENT that it is
> more POSIXly correct, provided that he interpreted POSIX correctly; how
> do other operating systems behave in this case?


There are two issues: the right thing to do for POSIX and
compatibility with older versions.

See the memory protection section in
http://www.opengroup.org/onlinepubs/...chap02_08.html

Excerpt:
* Write attempts to memory that was mapped without write access, or any
access to memory mapped PROT_NONE, shall result in a SIGSEGV signal.

* References to unmapped addresses shall result in a SIGSEGV signal.

* Reference to whole pages within the mapping, but beyond the current
length of the object, shall result in a SIGBUS signal.

FreeBSD's behavior until 7.0 was opposite of this! It has
followed what has been done at least since 4.3BSD (1986?)
which gave SIGBUS on a protection violation and SIGSEG for
access outside any mapped area.

Solaris mmap man page is not clear on this -- it says you can
get SIGSEGV or SIGBUS but doesn't indicate which under what
condition.

The change made for 7.0 doesn't quite do the right thing
either as it doesn't distinguish between unmapped area and
wrong kind of access -- you get SIGSEGV for both.

So you are breaking compatibility for no good reason.

Kris Kennaway argus
> it is far too late in the release cycle to identify and revert the ports
> that already caught up to expecting SIGSEGV, so we'd be breaking a
> different set of applications instead).


This is a mess but IMHO the two kinds of breakages are not
equal. For better standards compliance another kernel change
will have to be made in the future in any case.

FWIW.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"