[Mono-bugs] [Bug 70452][Maj] Changed - off-by-one in Mono.Posix.Signals

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
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 jonpryor@vt.edu.

http://bugzilla.ximian.com/show_bug.cgi?id=70452

--- 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 @@
 Bug#: 70452
 Product: Mono: Class Libraries
 Version: 1.1
-OS: 
+OS: unknown
 OS Details: 
-Status: NEW   
-Resolution: 
-Severity: 
+Status: RESOLVED   
+Resolution: NOTABUG
+Severity: Unknown
 Priority: Major
 Component: Mono.POSIX
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: james@ximian.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
@@ -16,6 +16,58 @@
 Cc: 
 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
 correct.
+
+------- Additional Comments From jonpryor@vt.edu  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
+libMonoPosixHelper.so.
+
+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.