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
0001302 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Enhancement Request 2019-11-19 15:27 2020-11-08 23:42
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Geoff Clare
Organization The Open Group
User Reference
Section (many)
Page Number (many)
Line Number (many)
Interp Status ---
Final Accepted Text
Summary 0001302: Alignment with C17
Description In Issue 8, align the standard with C17.

Note this bug has XBD as the category, but the changes affect all volumes.
Desired Action Apply the changes detailed in the attached document (whichever version is the latest at the time this bug is resolved - it is currently a work in progress).
Tags No tags attached.
Attached Files pdf file icon C17_alignment_20191119.pdf [^] (488,848 bytes) 2019-11-19 15:27
pdf file icon C17_alignment_20201102.pdf [^] (461,869 bytes) 2020-11-02 11:49
pdf file icon C17_alignment_20201102_diffs.pdf [^] (470,452 bytes) 2020-11-02 11:50

- Relationships
related to 0000411Appliedajosey 1003.1(2008)/Issue 7 adding atomic FD_CLOEXEC support 
related to 0000711Applied 1003.1(2013)/Issue7+TC1 Are the stdarg.h macros async-signal-safe? 
related to 0001163Applied 1003.1(2016/18)/Issue7+TC2 fscanf omits carriage in the list of white space character directives 

-  Notes
(0004663)
shware_systems (reporter)
2019-11-19 17:04

Editorial:
Line 741, noreturn shouldn't be plain text; either bold or tt-tagged.
A few macro definitions like this follow for other keyword equivalencies.
Having these and other macro definitions as run on sentences is also inconsistent with other headers where each identifier is on a separate line.

Objection:
The text does not carry into pthread_mutex_timedlock() the restriction with mtx_timedlock() that the initialization of the mtx_t value used specifies mtx_timed for it to return thrd_success. This requires modifying pthread_mutexattr_get/settype() or adding (sic) pthread_mutexattr_get/settimed() or ...setuntimed() as interfaces. The latter is preferable, even though this qualifies currently as invention, as the default for pthread_mutex_t currently is that they be usable with pthread_mutex_timedlock(), i.e. mtx_timed is presumed set. This is the one place where <threads.h> supersets <pthreads.h> in functionality, and I see it as on <pthreads.h> to change to accommodate this if the intent is all of <threads.h> be implementable as wrappers of <pthreads.h> interfaces.
(0004664)
geoffclare (manager)
2019-11-20 09:16

Re: Note: 0004663

> Line 741, noreturn shouldn't be plain text

If you look at other header pages you'll see that all macro names are plain text (except for function-like macros). If you have a problem with that, this is not the place to raise it.

> Having these and other macro definitions as run on sentences is also inconsistent with other headers where each identifier is on a separate line.

I will fix that for <threads.h> at line 794. If you found a similar problem elsewhere please let me know the line number(s) by email.

> The text does not carry into pthread_mutex_timedlock() the restriction with mtx_timedlock() that the initialization of the mtx_t value used specifies mtx_timed for it to return thrd_success.

I'll respond to this on the mailing list, to avoid starting a discussion in these bug notes. This is a long document, so if we are not careful we will end up with far too many notes in this bug.
(0004665)
dennisw (reporter)
2019-11-20 10:49

lines 2741-2830
The changes to fopen proposed here overlap with the changes to fopen accepted for 0000411.
These changes should either be rewritten to apply on top of 0000411 or the resolution to 0000411 should be changed to apply on top of these changes.

lines 4323-4325
"IEC 60559 implementations that support <complex.h>" does not seem correct to me.
An implementation can conform to Annex F of the C standard and provide the <complex.h> header without conforming to Annex G of the C standard.
Then that would be a conforming IEC 60559 implementation that supports <complex.h> but that does not implement the functionality specified by the MXC margin code.
(0004666)
geoffclare (manager)
2019-11-20 14:07

Re: Note: 0004665

> The changes to fopen proposed here overlap with the changes to fopen accepted for 0000411.

Thanks, I will update my proposed changes.

> "IEC 60559 implementations that support <complex.h>" does not seem correct to me.

I see your point. The XBD 1.7.1 addition already says "The functionality described is mandated by the ISO C standard only for implementations that define __STDC_IEC_559_COMPLEX__" so I think that second sentence in the XRAT A.1.7.1 addition could just be dropped.
(0005093)
geoffclare (manager)
2020-11-02 11:57
edited on: 2020-11-02 12:01

I have attached an updated version of the changes document as C17_alignment_20201102.pdf (clean version) and C17_alignment_20201102_diffs.pdf (diffmarked from 20191119 version).

Apart from the changes to address comments made here, most of the changes are related to the fopen() "exclusive access" issue. (The previous version said that it was "the subject of discussions in WG14 which hopefully will result in a clarification in C2x" but those discussions concluded without making any change.) There is also an addition about signal() thread-safety as discussed on the core mailing list.

If anyone has comments on the updated document, please use the line numbers from the clean version.

(0005108)
nick (manager)
2020-11-08 23:42

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


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