A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1302 
====================================================================== 
Reported By:                geoffclare
Assigned To:                
====================================================================== 
Project:                    1003.1(2016/18)/Issue7+TC2
Issue ID:                   1302
Category:                   Base Definitions and Headers
Type:                       Enhancement Request
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Geoff Clare 
Organization:               The Open Group 
User Reference:              
Section:                    (many) 
Page Number:                (many) 
Line Number:                (many) 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2019-11-19 15:27 UTC
Last Modified:              2020-11-08 23:42 UTC
====================================================================== 
Summary:                    Alignment with C17
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0000411 adding atomic FD_CLOEXEC support
related to          0000711 Are the stdarg.h macros async-signal-safe?
related to          0001163 fscanf omits carriage in the list of wh...
====================================================================== 

---------------------------------------------------------------------- 
 (0005108) nick (manager) - 2020-11-08 23:42
 https://austingroupbugs.net/view.php?id=1302#c5108 
---------------------------------------------------------------------- 
The following issue was pointed out by Hubert Tong in response to a request
for comments on the current draft to the C committee:

====================
C17 and POSIX wording issues for pow() domain errors for IEC 60559 (MX)


In C17 subclause 7.12.7.4 paragraph 2, regarding the pow() function:
A domain error occurs if x is finite and negative and y is finite and not
an integer value.

This is not consistent with subclause F.10.4.4 if -0 is negative.

A similar, more extensive problem, is present for POSIX.

The ERRORS section for pow() in POSIX.1-2017 XSH Chapter 3 indicates that a
Domain Error shall occur when "[the] value of x is negative and y is a
finite non-integer".
See https://pubs.opengroup.org/onlinepubs/9699919799/functions/pow.html

However, the RETURN VALUE section of the same says:
For y > 0 and not an odd integer, if x is ±0, +0 shall be returned.

For y < 0 and not an odd integer, if x is -Inf, +0 shall be returned.

For y > 0 and not an odd integer, if x is -Inf, +Inf shall be returned.

I would prefer for an implementation to be allowed to "report success" when
it provides the specified return value (regardless of whether it provides
the specified return value for other inputs).

What C17 says itself is likely wrong for -0. I believe I have pointed out a
self-inconsistency in POSIX: the optional behaviour specifies that there is
an exact, non-NaN value to return. When such a value is returned, there
should be no error condition.

>From IEEE 754:
Attempts to evaluate a function outside its domain shall return a quiet NaN
and signal the invalid operation exception.

Thus POSIX is both saying that it is non-optional for pow(-Inf, 0.5) to
report an error and that it may optionally return +Inf (which is a return
value not indicative of an error).

The change to correct this would be to update the ERRORs section to express
that the specified error only occurs when the implementation does not
return the value indicated for the optional behaviour in the RETURN VALUE
section 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2019-11-19 15:27 geoffclare     New Issue                                    
2019-11-19 15:27 geoffclare     File Added: C17_alignment_20191119.pdf          
         
2019-11-19 15:27 geoffclare     Name                      => Geoff Clare     
2019-11-19 15:27 geoffclare     Organization              => The Open Group  
2019-11-19 15:27 geoffclare     Section                   => (many)          
2019-11-19 15:27 geoffclare     Page Number               => (many)          
2019-11-19 15:27 geoffclare     Line Number               => (many)          
2019-11-19 15:27 geoffclare     Interp Status             => ---             
2019-11-19 17:04 shware_systems Note Added: 0004663                          
2019-11-20 09:16 geoffclare     Note Added: 0004664                          
2019-11-20 10:49 dennisw        Note Added: 0004665                          
2019-11-20 14:07 geoffclare     Note Added: 0004666                          
2019-11-20 15:41 geoffclare     Relationship added       related to 0000411  
2019-11-20 15:42 geoffclare     Relationship added       related to 0000711  
2019-11-20 15:42 geoffclare     Relationship added       related to 0001163  
2020-11-02 11:49 geoffclare     File Added: C17_alignment_20201102.pdf          
         
2020-11-02 11:50 geoffclare     File Added: C17_alignment_20201102_diffs.pdf    
               
2020-11-02 11:57 geoffclare     Note Added: 0005093                          
2020-11-02 12:01 geoffclare     Note Edited: 0005093                         
2020-11-08 23:42 nick           Note Added: 0005108                          
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Use... Geoff Clare via austin-group-l at The Open Group
        • ... Vincent Lefevre via austin-group-l at The Open Group
          • ... Geoff Clare via austin-group-l at The Open Group
            • ... Vincent Lefevre via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to