[Mono-bugs] [Bug 70452][Maj] Changed - off-by-one in Mono.Posix.Signals
Wed, 29 Dec 2004 09:28:13 -0500 (EST)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by firstname.lastname@example.org.
--- shadow/70452 2004-12-10 19:38:43.000000000 -0500
+++ shadow/70452.tmp.17389 2004-12-29 09:28:13.000000000 -0500
@@ -1,14 +1,14 @@
Product: Mono: Class Libraries
@@ -16,6 +16,58 @@
Summary: off-by-one in Mono.Posix.Signals
The 'Signals' enum in Mono.Posix has the wrong values for the signal
numbers. It should start from 1, not zero. Mono.Unix.Signum, however, is
+------- Additional Comments From email@example.com 2004-12-29 09:28 -------
+This isn't a bug. It's a feature! :-)
+Joking aside, this isn't a bug. Symbolic constants such as signal
+names (SIGHUP, SIGKILL, etc.) and Error values (EPERM, EINTR) are not
+guaranteed to be portable, *at all*. They can (and do) differ between
+Unixes (e.g. Sparc/Solaris vs x86/Linux vs x86/SCO vs...).
+For example, ENETDOWN on Linux is 100 while it's 50 on *BSD (*BSD
+value seen here: http://fxr.watson.org/fxr/source/sys/errno.h?v=RELENG52).
+Signals aren't portable either: SIGBUS is 7 on Linux and 10 on *BSD.
+Consequently, you CANNOT use managed enumeration values portably
+across the various Unixes anyway, *unless* you know that they share
+the same value. (And since, as you noted, the managed values are
+off-by-1 from Linux, they won't be valid on *any* platform.)
+The solution? A mapping mechanism. Make-map.cs generates C functions
+which will convert the managed value to the appropriate,
+platform-specific, unmanaged value. These functions are in
+The only "bug" is that Mono.Posix doesn't expose any way to convert
+the Signals values to their unmanaged values, which is somewhat
+excusable since Signals isn't actually *used* anywhere in Mono.Posix
+(by name; kill(2) and others should use it, and this is the real issue
+-- not all functions which accept signal values take Signals as a
+parameter, they take an int, which is unsafe and non-portable).
+A solution would be to overload kill(2) (and others) to take Signals
+as a parameter, which would convert the managed value to the unmanaged
+value. However, this won't fix the problem (as the unsafe "int"
+equivalent is still available, and we can't remove it without breaking
+existing code). *Furthermore*, since the original symbolic value
+mapping code only provided managed -> unmanaged conversions (and not
+unmanaged -> managed), functions which return a Signal value from
+unmanaged code, such as WTERMSIG, will *always* return the unmanaged
+value, and there's no way to convert that to the managed equivalent
+(which would be necessary for any type of comparison in managed code).
+In short, the original Mono.Posix approach is broken, and fixing it
+wouldn't fix any existing code (for compatibility reasons). If we
+didn't care about compatibility, Mono.Unix wouldn't exist (it would
+*be* Mono.Posix, fixing all these issues), but we tried that approach
+and it broke too much existing code.
+So, it's NOTABUG (that's what the C conversion functions are for), and
+even if it were, it would be WONTFIX (since we can't properly fix this
+on 1.0.5 because of WTERMSIG). Just use Mono.Unix which fixes all
+these issues. Please.