View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00008281003.1(2013)/Issue7+TC1Base Definitions and Headerspublic2014-02-20 17:122024-06-11 09:02
Reporternick Assigned To 
PrioritynormalSeverityEditorialTypeEnhancement Request
Status ClosedResolutionAccepted As Marked 
NameNick Stoughton
OrganizationUSENIX
User Reference
Sectionmath.h
Page Number289-290
Line Number9595-9609
Interp Status---
Final Accepted Textsee 0000828:0002189
Summary0000828: Additional M_ constants for math.h
DescriptionDiscussion 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 ActionChange 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 ]
Tagsissue8

Relationships

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

Activities

geoffclare

2014-02-21 10:09

manager   bugnote:0002150

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.

eblake

2014-03-20 16:30

manager   bugnote:0002189

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.

eblake

2014-03-20 16:33

manager   bugnote:0002190

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 0000828: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
2024-06-11 09:02 agadmin Status Applied => Closed