Re: 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(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

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(at)svana(dot)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(at)fuhr(dot)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(at)fuhr(dot)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