Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000828 [1003.1(2013)/Issue7+TC1] Base Definitions and Headers Editorial Enhancement Request 2014-02-20 17:12 2020-03-25 16:05
Reporter nick View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Nick Stoughton
Organization USENIX
User Reference
Section math.h
Page Number 289-290
Line Number 9595-9609
Interp Status ---
Final Accepted Text see Note: 0002189
Summary 0000828: Additional M_ constants for math.h
Description Discussion of 0000801 revealed a need for versions of the mathematical constants given in math.h where the underlying type is long double, not double.

Existing implementations are common where there are, for example two versions of M_PI:
#define M_PI    3.14159265358979323846
#define M_PIl   3.141592653589793238462643383279502884L


This uses the l (lower-case ell) suffix to show long double.
Desired Action Change lines 9595 - 9609 to read:

The <math.h> header shall define the following symbolic constants. Where the constant name ends in "l" (lower case ell), the values shall have type long double and shall be accurate to at least the precision of the long double type. Otherwise, the values shall have type double and shall be accurate to at least the precision of the double type and the macros shall either include an explicit cast to type double, or shall be expressed as hexadecimal floating constants with the precision of double.
M_E       Value of e
M_El      Value of e
M_LOG2E   Value of log2 e
M_LOG2El  Value of log2 e
M_LOG10E  Value of log10 e
M_LOG10El Value of log10 e
.
.
.

[ note to editor: duplicate each line in this table, and add a "l" suffix to the each duplicated name ]
Tags issue8
Attached Files

- Relationships
child of 0000801Closed Clarify requirements on M_* macros with FLT_EVAL_METHOD!=0 

-  Notes
(0002150)
geoffclare (manager)
2014-02-21 10:09

For consistency there should be an explicit-cast-or-hex requirement for the new long double constants that matches the one for the double constants.

Also, when this requirement comes in the application usage added in 0000801 warning that (double)M_PI == M_PI can fail will no longer be needed, so this bug should include a change that removes it.
(0002189)
eblake (manager)
2014-03-20 16:30

Change lines 9595 - 9609 to read:

    <XSI>The <math.h> header shall define the following symbolic constants. Where the constant name ends in "l" (lower case ell), the values shall have type long double; otherwise the values shall have type double. The values shall be accurate to the precision of their type. If the implementation supports FLT_EVAL_METHOD values other than 0 or 1, the values shall either include an explicit cast for that type, or be expressed as hexadecimal floating constants.


    Double Long Double Value
    ---------- ------------ ----------------
    M_E M_El Value of e
    M_LOG2E M_LOG2El Value of log2 e
    M_LOG10E M_LOG10El Value of log10 e
    ...
    M_SQRT1_2 M_SQRT1_2l Value of 1/sqrt2

    </XSI>

Remove the following application usage addition from 0000801 (p 295, line 9860):

    Note that if FLT_EVAL_METHOD is neither 0 nor 1, then some constants might not compare equal as expected, for example (double)M_PI == M_PI can fail.

Add Rationale text on page 295 after line 9867:

    The requirement for an explicit cast or representation via hexadecimal floating constants is to guarantee that even when FLT_EVAL_METHOD is neither 0 nor 1, the expression (double)M_PI == M_PI will always hold true. Earlier versions of this standard did not make this requirement, because they lacked the "l" (lower case ell) versions of the constants and were allowed to provide M_PI with long double precision depending on FLT_EVAL_METHOD.
(0002190)
eblake (manager)
2014-03-20 16:33

The set of constants exposed in this bug may be worth promoting to the base requirements (with <CX> shading, unless the C standard also requires the constants) instead of the current <XSI> shading. But such a change in shading belongs in a separate bug report.

- Issue History
Date Modified Username Field Change
2014-02-20 17:12 nick New Issue
2014-02-20 17:12 nick Name => Nick Stoughton
2014-02-20 17:12 nick Organization => USENIX
2014-02-20 17:12 nick Section => math.h
2014-02-20 17:12 nick Page Number => 289-290
2014-02-20 17:12 nick Line Number => 9595-9609
2014-02-20 17:12 nick Interp Status => ---
2014-02-20 17:12 nick Issue generated from 0000801
2014-02-20 17:12 nick Relationship added child of 0000801
2014-02-20 17:15 nick Desired Action Updated
2014-02-20 17:21 nick Description Updated
2014-02-20 17:23 nick Description Updated
2014-02-20 17:23 nick Description Updated
2014-02-21 10:09 geoffclare Note Added: 0002150
2014-02-21 10:09 geoffclare Tag Attached: issue8
2014-03-20 16:30 eblake Note Added: 0002189
2014-03-20 16:30 eblake Final Accepted Text => see Note: 0002189
2014-03-20 16:30 eblake Status New => Resolved
2014-03-20 16:30 eblake Resolution Open => Accepted As Marked
2014-03-20 16:33 eblake Note Added: 0002190
2020-03-25 16:05 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker