Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler |
Дата | |
Msg-id | 26256.911922943@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes: >> 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. > OK, sounds good. OK, I'll do something about it this weekend, unless someone beats me to it. >> 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... AFAICS, *any* error out of the pow() ought to be treated the same. So what I was actually planning to do was errno = 0;result = pow(...);if (errno != 0) ELOG(...); which is probably a cycle or two faster than what we have, since testing against zero is usually a shade cheaper than comparison to a nonzero constant. Not that a cycle or three saved or wasted in a pow() function evaluation is going to be significant, or even measurable ;-) regards, tom lane
В списке pgsql-hackers по дате отправления: