On 2008-05-19 at 17:08:43 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > > The latest and current POSIX standard demands that error codes have to > be positive numbers. > Since this would cause a great deal of changes and possible > compatibility problems for Haiku, I would like to get our POV to the > people responsible for revising those standards. > It looks like the OpenGroup Austin Group maintains the POSIX standard, > and I just subscribed to a public mailing list where we can actually > make our voice heard. > > I would like to submit the following mail there: > -------------8<------------ > Subject: Positive error codes since Issue 6 > > The change history of POSIX errno states for issue 6: > "Values for errno are now required to be distinct positive values > rather than non-zero values. This change is for alignment with the ISO/ > IEC 9899:1999 standard." > > I'm writing on behalf of the Haiku project (http://www.haiku-os.org/) > which is an open source implementation of BeOS. > In BeOS, the values for errno were actually defined as negative values, > and software written for BeOS may rely on that. BeOS is older than the > ISO 1999 standard, and hence, it does not comply to it. Since Haiku is > compatible with BeOS, we're bound to the same restriction. > > Not surprisingly, there are already applications out there that assume > positive error codes, and those are hard to port to our otherwise POSIX > compliant system. > > Is there any way this change can be reverted, or limited in a way that > allows Haiku to be POSIX compliant without breaking compatibility with > previous versions of BeOS? > > -------------8<------------ > > Any comments, or suggestions for improvements? I would be more careful with the term "POSIX compliant". Haiku is still quite a bit away, and BeOS was worse. Anyway, it certainly doesn't harm to try, but I have little hope that this will have any effect. If the standard maintainers consider the request, they are in a dilemma. Undoing the Issue 6 error codes change means that all the applications that relied on it would become non-conforming. CU, Ingo