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 2024-06-11 09:08
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
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 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
pdf file icon C17_alignment_20210813.pdf [^] (462,897 bytes) 2021-08-13 11:10
pdf file icon C17_alignment_20210813_diffs.pdf [^] (473,055 bytes) 2021-08-13 11:11
pdf file icon C17_alignment_20211019.pdf [^] (467,084 bytes) 2021-10-19 08:55
pdf file icon C17_alignment_20211019_diffs.pdf [^] (481,955 bytes) 2021-10-19 08:55

- Relationships
related to 0000411Closedajosey 1003.1(2008)/Issue 7 adding atomic FD_CLOEXEC support 
related to 0000711Closed 1003.1(2013)/Issue7+TC1 Are the stdarg.h macros async-signal-safe? 
related to 0001163Closed 1003.1(2016/18)/Issue7+TC2 fscanf omits carriage in the list of white space character directives 
related to 0001428Closed 1003.1(2016/18)/Issue7+TC2 Add definitions of "negative" and "positive" 
related to 0000609Closedajosey 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 0001526Closed Issue 8 drafts Update fdopen() mode description to match new fopen() terminology 
related to 0001524Closed Issue 8 drafts open() flags used by fopen() 
related to 0000792Closed 1003.1(2013)/Issue7+TC1 better definition of thread lifetime 
related to 0001646Closed Issue 8 drafts exec*() misses reference to at_quick_exit() 
related to 0001860Resolved 1003.1(2024)/Issue8 kill_dependency() SYNOPSIS has type* instead of type 

-  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
(0005442)
geoffclare (manager)
2021-08-13 10:03

Re: Note: 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).
(0005443)
geoffclare (manager)
2021-08-13 11:12

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.
(0005506)
geoffclare (manager)
2021-10-19 09:00
edited on: 2021-10-19 09:01

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().


- 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
2020-11-27 14:57 geoffclare Relationship added related to 0001428
2020-12-21 02:36 jscott0 Issue Monitored: jscott0
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


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