hi, Yes Chris is right , the test was written for SUSv2. Also since a warning is being output this is not something we would worry about in for certification. We could consider allowing the warning case in the code to also omit pass since the future directions have gone that way. SUSv3 is now more explicit in this area, having the MX extension (floating point maths) with pole errors etc being described.
best regards Andrew On Feb 26, 3:23pm in "Re: /tset/ANSI.os/ma", Christopher Yeoh wrote: > At 2002/2/25 16:31-0500 Dave Prosser writes: > > Matt Wilson wrote: > > > From lsb-distribution-test-1.1.3-1 > > > > > > ************************************************************************ > > > /tset/ANSI.os/maths/pow/T.pow 4 Warning > > > > > > Test Information: > > > pow(0.0, -1.0) gave > > > RETURN VALUES: expected: -inf, observed: inf > > > Bit Representation: expected value: \000\000\000\000\000\000\360\377 > > > Bit Representation: observed value: \000\000\000\000\000\000\360\177 > > > > > > ************************************************************************ > > > > > > Isn't pow(0.0, -1.0) undefined? From the looks of C99, pow(long > > > double x, long double y) may cause a domain error if x is zero and y > > > is less than or equal to zero. > > > > For IEEE F.P. systems, C99 says (F.9.4.4): > > > > pow(+-0, y) returns +-infinity and raises the "divide-by-zero" > > floating point exception for y an odd integer < 0. > > > > So the problem with the test is that it expects the wrong sign > > for the infinity returned given the information in your message. > > That tests suite was written for POSIX.1-1990. I don't have a copy of > that, but SUSv2 states: > > If x is 0.0 and y is negative, -HUGE_VAL is returned and errno may be > set to [EDOM] or [ERANGE]. > > So I'm guessing the specification changed since the test was written. > I think we classify Warnings as Pass anyway (Andrew please correct me > if I'm wrong) so we might not have to worry about this one. If not, it > appears to be following future behaviour so it should be waived > regardless. > > Regards, > > Chris > -- > [EMAIL PROTECTED] > IBM OzLabs Linux Development Group > Canberra, Australia > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED] >-- End of excerpt from Christopher Yeoh
