|
Home About Us A-Z Index Search * Contact Us Register Login Press ShopThe Open Brand -- Problem Reporting and Interpretations System |
Problem Report 0487 Details
Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges
This page provides all information on Problem Report 0487.
Report 0487 Actions
Problem Report Number 0487 Submitter's Classification Test Suite problem State Resolved Resolution Rejected (REJ) Problem Resolution ID REJ.X.0106 Raised 1995-07-20 08:00 Updated 2003-03-13 08:00 Published null Product Standard Internationalised System Calls and Libraries (XPG4) Certification Program The Open Brand certification program Test Suite VSX4 version 4.3.5 Test Identification XPG4.hdr/misc/float 4 Problem Summary PG4R.107 Test makes underlying hardware assumption. We fail this test case because the test suite expects the floating-point (FP) model defined in <float.h> to equal the precision of the underlying hardware. I... Problem Text
Test makes underlying hardware assumption.
We fail this test case because the test suite expects the floating-point
(FP) model defined in <float.h> to equal the precision of the underlying
hardware.
In looking at section 2.2.4.2.2 of the ANSI C standard, we see no
requirement for the values defined in <float.h> to equal the maximum
possible value the hardware can represent. All values included in
<float.h> are defined in terms of the FP model. Our FP model is well
documented and meets the requirements of the ANSI C standard. The test
suite should not test for behavior outside the scope of the base
standard.
We believe this test should be changed to verify that the computed
values are greater-than-or-equal in magnitude (absolute value) to
the values defined in <float.h>. This will verify the FP model and
not the hardware.Test Output
************************************************************************
/tset/XPG4.hdr/misc/float/T.float 4 Failed
Test Description:
When the values for the following symbolic names can be determined
arithmetically, then the symbolic names evaluate to the same value:
FLT_DIG, DBL_DIG, LDBL_DIG, FLT_MIN_EXP, DBL_MIN_EXP, LDBL_MIN_EXP,
FLT_MIN_10_EXP, DBL_MIN_10_EXP, LDBL_MIN_10_EXP, FLT_MAX_EXP,
DBL_MAX_EXP, LDBL_MAX_EXP, FLT_MAX_10_EXP, DBL_MAX_10_EXP,
LDBL_MAX_10_EXP, FLT_MAX, DBL_MAX, LDBL_MAX, FLT_EPSILON, DBL_EPSILON,
LDBL_EPSILON, FLT_MANT_DIG, DBL_MANT_DIG, LDBL_MANT_DIG, FLT_MIN,
DBL_MIN, LDBL_MIN and FLT_RADIX.
Test Information:
Feature test macros: -D_XOPEN_SOURCE
Compiler or run-time messages or results:
Value of FLT_MIN_EXP is incorrect
Observed: -8189
Expected: -8192
Value of FLT_MIN is incorrect
Observed: 3.66720773511e-2466
Expected: 0
Value of FLT_MIN_10_EXP is incorrect
Observed: -2465
Expected: -2466
Value of FLT_DIG is incorrect
Observed: 13
Expected: 14
Value of FLT_MANT_DIG is incorrect
Observed: 47
Expected: 48
Value of DBL_MIN_EXP is incorrect
Observed: -8189
Expected: -8192
Value of DBL_MIN is incorrect
Observed: 3.66720773511e-2466
Expected: 0
Value of DBL_MIN_10_EXP is incorrect
Observed: -2465
Expected: -2466
Value of DBL_DIG is incorrect
Observed: 13
Expected: 14
Value of DBL_MANT_DIG is incorrect
Observed: 47
Expected: 48
Value of LDBL_MIN_EXP is incorrect
Observed: -8189
Expected: -8192
Value of LDBL_MIN is incorrect
Observed: 3.66720773510972502543901904e-2466
Expected: 0
Value of LDBL_MIN_10_EXP is incorrect
Observed: -2465
Expected: -2466
Value of LDBL_DIG is incorrect
Observed: 27
Expected: 28
Value of LDBL_MANT_DIG is incorrect
Observed: 94
Expected: 96
************************************************************************Review Information
Review Type TSMA Review Start Date null Completed null Status Complete Review Recommendation No Resolution Given Review Response
There are two separate issues here. The first is the claim by the
submitter that the values defined in <float.h> do not have to reflect
the hardware capabilities of the implementation. This may be a valid
question for some <float.h> values, but not for others. For example
the values of FLT_EPSILON, DBL_EPSILON and LDBL_EPSILON are defined to
be "the difference between 1.0 and the least value greater than 1.0 that
is representable in the given floating-point type." It seems clear
that these values must reflect the floating point representation used
for the types float, double and long double in the way specified.
However for values such as FLT_MIN_EXP, DBL_MIN_EXP and LDBL_MIN_EXP the
definition is only given in terms of the model, and it may be that
implementors can have a some degree of choice in defining these values.
This is a matter that should be decided through the C standard
interpretations process.
The second issue is the claim by the submitter that the values defined
in <float.h> meet the requirements of the model. Since the test has not
reported that FLT_EPSILON is incorrect, this raises the question of
whether the implementation meets the requirement that FLT_EPSILON is
equal to FLT_RADIX raised to the power of (1 - FLT_MANT_DIG), and likewise
for DBL_EPSILON and LDBL_EPSILON. It will be necessary to ask the
submitter to supply these values in order to verify this.
It recommended that this request be refused on the grounds that further
supporting information is needed. If this is supplied in a resubmission
of this request, and is found to be satisfactory, then a temporary
interpretation should be granted, pending an ISO C interpretation.
Review Type SA Review Start Date null Completed null Status Complete Review Resolution Rejected (REJ) Review Conclusion
This request is refused. Please refer to TIN4.010.
Problem Reporting System Options:
- View Report 0487
- List All PRs
- Search Reports
- Email the System Administrator
- View the The Open Brand Interpretations Database User Manual
Contact the Certification Authority