Thread: ECPG/OpenBSD buildfarm failures, take I
It seems ECPG regression tests trigger a bug in OpenBSD libc. Please try the attached test case. I should give ERANGE as error, but on OpenBSD errno is set to 0. I tried this test case on Linux, where it works, and OpenBSD 3.8 and 4.0 (that is HEAD). On both these systems it doesn't. Now the question is what do we do? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Attachment
Michael Meskes wrote: > It seems ECPG regression tests trigger a bug in OpenBSD libc. Please try > the attached test case. I should give ERANGE as error, but on OpenBSD > errno is set to 0. > > I tried this test case on Linux, where it works, and OpenBSD 3.8 and 4.0 > (that is HEAD). On both these systems it doesn't. Now the question is > what do we do? well it's even more interesting that it gives the correct answer on spoonbill (the OpenBSD/Sparc64 box on the buildfarm) - I have forwarded that testcase to the openbsd-tech list maybe we get an answer there ... Stefan
Michael Meskes wrote: > It seems ECPG regression tests trigger a bug in OpenBSD libc. Please try > the attached test case. I should give ERANGE as error, but on OpenBSD > errno is set to 0. > > I tried this test case on Linux, where it works, and OpenBSD 3.8 and 4.0 > (that is HEAD). On both these systems it doesn't. Now the question is > what do we do? a bit of testing shows that at least FreeBSD 4.10 behaves similiar to OpenBSD/i386 and I found the following discussion too: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3759+0+archive/2003/freebsd-standards/20030511.freebsd-standards that hints that setting ERANGE on an underflow (vs an overflow) is implementation specific though I ws unable to verify that this is indeed the case ... Stefan
On Wed, Sep 06, 2006 at 09:13:34PM +0200, Stefan Kaltenbrunner wrote: > that hints that setting ERANGE on an underflow (vs an overflow) is > implementation specific though I ws unable to verify that this is indeed > the case ... Odd, according to these references: http://www.csse.uwa.edu.au/programming/ansic-library.html#stdlib http://cplus.kompf.de/cliblist.html http://docs.hp.com/en/B9106-90010/strtod.3C.html returning ERANGE on underflow was in the ANSI C standard. Can't find the text itself though, Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On Wed, Sep 06, 2006 at 11:20:12PM +0200, Martijn van Oosterhout wrote: > Odd, according to these references: > > http://www.csse.uwa.edu.au/programming/ansic-library.html#stdlib > http://cplus.kompf.de/cliblist.html > http://docs.hp.com/en/B9106-90010/strtod.3C.html > > returning ERANGE on underflow was in the ANSI C standard. > > Can't find the text itself though, In Plauger's _The Standard C Library_ (1992) on p 335 is an excerpt from the standard (I think). At the end of a section entitled "7.10.1.4 The strtod function" is the following: "If the correct value would cause underflow, zero is returned and the value of the macro ERANGE is stored in errno." I don't know how much weight a reference that old still has, but it does show that ERANGE on underflow has been defined for a long time. The Open Group Base Specifications Issue 6 (2004) also documents ERANGE on underflow: "If the correct value would cause an underflow, a value whose magnitude is no greater than the smallest normalized positive number in the return type shall be returned and errno set to [ERANGE]." I'd post the link but they want people to register to read the specification; you can get there from here: http://www.opengroup.org/online-pubs-short?DOC=9699959299&FORM=HTML -- Michael Fuhr
Michael Fuhr <mike@fuhr.org> writes: > In Plauger's _The Standard C Library_ (1992) on p 335 is an excerpt > from the standard (I think). At the end of a section entitled > "7.10.1.4 The strtod function" is the following: "If the correct > value would cause underflow, zero is returned and the value of the > macro ERANGE is stored in errno." The Single Unix Spec also makes it clear that ERANGE on underflow is not optional: http://www.opengroup.org/onlinepubs/007908799/xsh/strtod.html I think there is no question that OpenBSD is broken. The question for us is whether we should expend effort to work around that. We already have a "small-is-zero" workaround comparison file in the main regression tests, so my thought is that ecpg should probably do likewise ... regards, tom lane
Tom Lane wrote: > Michael Fuhr <mike@fuhr.org> writes: >> In Plauger's _The Standard C Library_ (1992) on p 335 is an excerpt >> from the standard (I think). At the end of a section entitled >> "7.10.1.4 The strtod function" is the following: "If the correct >> value would cause underflow, zero is returned and the value of the >> macro ERANGE is stored in errno." > > The Single Unix Spec also makes it clear that ERANGE on underflow is not > optional: > http://www.opengroup.org/onlinepubs/007908799/xsh/strtod.html > > I think there is no question that OpenBSD is broken. The question for > us is whether we should expend effort to work around that. We already > have a "small-is-zero" workaround comparison file in the main regression > tests, so my thought is that ecpg should probably do likewise ... The openbsd guys are already aware of the issue and working on a solution: http://marc.theaimsgroup.com/?l=openbsd-tech&m=115756205505000&w=2 Stefan