[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 <--
- Meaning of sys_nerr (and porting programs),
Wolfgang Jährling <=