bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Meaning of sys_nerr (and porting programs)


From: Wolfgang Jährling
Subject: Meaning of sys_nerr (and porting programs)
Date: Sun, 13 Jan 2002 02:38:44 +0100
User-agent: Mutt/1.0.1i

Hi!

[ This message is about a general issue in GNU/Hurd, which i encountered
  during i tried to fix Ruby, thus I think it's most relevant for this
  list. ]

I tried to find out more about the problem with the E* constants in
Ruby. I found out that Ruby does the following:

It allocates an array of sys_nerr elements (the sys_nerr in glibc on
GNU/Hurd is 119) and tries to store an object for each E* constant in
one of those elements, but uses the actual value of the constant as
offset. However, it doesn't crash while doing this on GNU/Hurd, because
it checks if the number is smaller or equal to sys_nerr and if it is
not, it simply does not copy it into the array.

I am not shure if this actually is the problem (I get a very strange
result when using Bignums instead of Fixnums for storing the errno
constants; it seems to call a method of an object which has no class at
all, which should be impossible in Ruby), but even if this does not
cause _any_ harm in the case of Ruby, this shows some general problem:

Programs might (and in fact do) assume that sys_nerr is the biggest
numeric value of any errno constant, which is not the case on GNU/Hurd.
This might cause strange bugs. We would recognise such a problem when
working with the program, but not during compilation.

For me, this looks similar to the problem with PATH_MAX, which we don't
define as UINT_MAX (which should be the current theoretical limit), but
not define at all. We could stop defining sys_nerr in glibc (programs
that use it should be fixed anyway, shouldn't they?), and indeed
<http://www.delorie.com/djgpp/doc/libc/libc_748.html> claims that it's
neither POSIX nor ANSI, but Manuel Menal wrote (on #hurd):

"sys_nerr is SVID2, SVID3, XPG2 according to a manpage from HP-UX
 r10.20. It also states: ssys_nerr is the largest message number provided
 for in the table; it should be checked because new error codes might be
 added to the system before they are added to the table."

I guess that "the table" is reffering to sys_errlist[]. Since we do not
have this, it would be interesting to see if one of these standards
defines what the meaning of sys_nerr should be if there is no such
table.

Ok, so what should we done?

Cheers,
GNU/Wolfgang

-- 
Wolfgang Jährling <wolfgang@pro-linux.de> `-:._ "Omnis enim res, quae dando
Debian GNU/Linux user && Debian GNU/Hurd user  `-:. non deficit, dum habetur
Hurd Hacking Guide - http://stdio.cjb.net/hhg.html )  et non datur, nondum
www.debian.org || www.gnu.org || hurd.gnu.org _,-:' habetur, quomodo habenda
["Accelerate your PC - with 9.81 m/s^2."] ,-:'   est." --> fsfeurope.org <--



reply via email to

[Prev in Thread] Current Thread [Next in Thread]