View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001302 | 1003.1(2016/18)/Issue7+TC2 | Base Definitions and Headers | public | 2019-11-19 15:27 | 2024-06-11 09:08 |
| Reporter | geoffclare | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Enhancement Request |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | (many) | ||||
| Page Number | (many) | ||||
| Line Number | (many) | ||||
| Interp Status | --- | ||||
| Final Accepted Text | See the attached document C17_alignment_20211019.pdf | ||||
| 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 | issue8 | ||||
| Attached Files | |||||
| related to | 0000411 | Closed | ajosey | 1003.1(2008)/Issue 7 | adding atomic FD_CLOEXEC support |
| related to | 0000711 | Closed | 1003.1(2013)/Issue7+TC1 | Are the stdarg.h macros async-signal-safe? | |
| related to | 0001163 | Closed | 1003.1(2016/18)/Issue7+TC2 | fscanf omits carriage in the list of white space character directives | |
| related to | 0001428 | Closed | 1003.1(2016/18)/Issue7+TC2 | Add definitions of "negative" and "positive" | |
| related to | 0000609 | Closed | ajosey | 1003.1(2004)/Issue 6 | It is not clear what threads are considered blocked with respect to a call to pthread_cond_signal() or pthread_cond_broadcast() |
| related to | 0001526 | Closed | Issue 8 drafts | Update fdopen() mode description to match new fopen() terminology | |
| related to | 0001524 | Closed | Issue 8 drafts | open() flags used by fopen() | |
| related to | 0000792 | Closed | 1003.1(2013)/Issue7+TC1 | better definition of thread lifetime | |
| related to | 0001646 | Closed | Issue 8 drafts | exec*() misses reference to at_quick_exit() | |
| related to | 0001860 | Resolved | 1003.1(2024)/Issue8 | kill_dependency() SYNOPSIS has type* instead of type |
|
|
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. |
|
|
Re: 0001302: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. |
|
|
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. |
|
|
Re: 0001302: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. |
|
|
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. |
|
|
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 |
|
|
Re: 0001302:0005108 Hubert says "if -0 is negative" but the C17 text "if x is finite and negative" is clearly referring to the value of x, not its sign, so -0 is not "finite and negative" and there is no problem there. He does identify a genuine problem in POSIX, but it is editorial - the ERRORS section text for Domain Error is missing the condition that x is finite, but it is present in the RETURN VALUE section (line 50711 in the 2018 edition). This should be submitted as a separate bug (targeted at TC3). |
|
|
I have attached an updated version of the changes document as C17_alignment_20210813.pdf (clean version) and C17_alignment_20210813_diffs.pdf (diffmarked from 20201102 version). The changes address the effects of bugs 374, 1218, and 1426. While working on the changes to 4.12 Memory Synchronization for bug 1426, I also added a paragraph there based on the following text about mutexes from C17 7.26.4, but generalised to apply to all synchronization objects: For purposes of determining the existence of a data race, lock and unlock operations behave as atomic operations. All lock and unlock operations on a particular mutex occur in some particular total order. |
|
|
I have made the updates to the changes document that were agreed in the Oct 14th teleconference and attached the new version as C17_alignment_20211019.pdf (clean version) and C17_alignment_20211019_diffs.pdf (diffmarked from 20210813 version). The changes since the last version are almost all related to fopen() and freopen(). |
| 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 | |
| 2020-11-27 14:57 | geoffclare | Relationship added | related to 0001428 |
| 2021-08-13 10:03 | geoffclare | Note Added: 0005442 | |
| 2021-08-13 11:10 | geoffclare | File Added: C17_alignment_20210813.pdf | |
| 2021-08-13 11:11 | geoffclare | File Added: C17_alignment_20210813_diffs.pdf | |
| 2021-08-13 11:12 | geoffclare | Note Added: 0005443 | |
| 2021-10-15 08:32 | geoffclare | Relationship added | related to 0000609 |
| 2021-10-19 08:55 | geoffclare | File Added: C17_alignment_20211019.pdf | |
| 2021-10-19 08:55 | geoffclare | File Added: C17_alignment_20211019_diffs.pdf | |
| 2021-10-19 09:00 | geoffclare | Note Added: 0005506 | |
| 2021-10-19 09:01 | geoffclare | Note Edited: 0005506 | |
| 2021-10-19 10:58 | geoffclare | Relationship added | related to 0001526 |
| 2021-10-21 15:24 | Don Cragun | Final Accepted Text | => See the attached document C17_alignment_20211019_diffs.pdf |
| 2021-10-21 15:24 | Don Cragun | Status | New => Resolved |
| 2021-10-21 15:24 | Don Cragun | Resolution | Open => Accepted As Marked |
| 2021-10-21 15:25 | Don Cragun | Final Accepted Text | See the attached document C17_alignment_20211019_diffs.pdf => See the attached document C17_alignment_20211019.pdf |
| 2021-10-21 15:25 | Don Cragun | Tag Attached: issue8 | |
| 2022-01-07 10:07 | geoffclare | Relationship added | related to 0001524 |
| 2022-02-21 11:59 | geoffclare | Status | Resolved => Applied |
| 2022-08-02 14:55 | geoffclare | Relationship added | related to 0000792 |
| 2023-03-23 10:02 | geoffclare | Relationship added | related to 0001646 |
| 2024-06-11 09:08 | agadmin | Status | Applied => Closed |
| 2024-10-07 08:16 | geoffclare | Relationship added | related to 0001860 |
