Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler |
Дата | |
Msg-id | 365A1B7C.BFA9C00E@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
|
Список | pgsql-hackers |
> > The reference platform never lies. > In this case the reference platform is broken, IMHO. Uh, yes. I was hoping that my statement was outrageous enough to be prima facia absurd. Ha Ha. Pretty funny, eh? > 1. Follow the ANSI spec and raise an error for exp() underflow. > The ERRNO path is already OK for this, but the other would have > to be made to read > if (!finite(*result) || *result == 0.0) > and we'd have to fix the expected regress output. > 2. Decide that we are smarter than the ANSI C authors and the > inventors of libm, and that a small exp() result should quietly > underflow to zero. In that case the ERRNO path would have to read > if (errno == ERANGE && *result != 0.0) > I like choice #1 myself. OK, sounds good. > BTW, while I was at it I took the time to figure out why the > pow() part of the test was failing for me (I was getting zeroes > instead of the expected "pow() result is out of range" error). > Turns out that depending on which HPUX math library version you > use, pow() might fail with EDOM rather than ERANGE for negative > inputs. I'll change the pow() code to check for either errno > when I get a chance. Hmm. Any chance of making that HP-specific? It would be a shame to make every platform test for two values on every calculation... Regards. - Tom
В списке pgsql-hackers по дате отправления: