View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000784 | 1003.1(2013)/Issue7+TC1 | Shell and Utilities | public | 2013-11-03 11:03 | 2019-06-10 08:55 |
| Reporter | shware_systems | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Mark Ziegast | ||||
| Organization | |||||
| User Reference | |||||
| Section | c99 | ||||
| Page Number | 2520 | ||||
| Line Number | 81306-7 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | See 0000784:0002085. | ||||
| Summary | 0000784: Obsolete, deprecate, or keep unchanged? | ||||
| Description | The standard currently has many instances where it defers to, supersedes, or extends the C standard, in a generic fashion. The implication is the version of the standard when the base POSIX issue was finalized for balloting. For Issue 6 and 7 this has been the c99 standard. For Issue 5 it was c89. As a number of Mantis ERNs are already targeting Issue 8, for whenever that gets released, I think the Future Directions section for c99 should be updated for TC2 to reflect a decision on whether: a) the current or next C standard version, c11 or c14-5, is expected to be switched to, obsoleting c99; b) some or all c11+ features may be supported as a new option group or groups with a c11 compiler as part of these, and c99 deprecated; or c) there are no plans to change from c99 as the only required C compiler environment. Making it a part of the TC also gives notice to those people that cast ballots but don't pay all that much attention to the mailing list what these plans are, in case there is a strong dissenting opinion the working group should take into account. I realize which version of C will be current when the features to be added to Issue 8 are finalized is not under POSIX control, but c99 is no longer the current version so I think something definitive should be added now about its ongoing role with the standard. This would be a firmer guide to what is plausible for further Issue 8 requests. As relatively few interface additions or changes were added to c11 it seems to me b) is a viable concept as a starting point, and may be less controversial than a) or c). They aren't as glaringly large a change as the addition of the 'restrict' keyword was on Issue 6, at least. There could be a group for changes introduced in c11 that are fully backwards compatible with c99, and one for those changes that rely on new language features of c11. As a related matter, and I've no firm opinion on this, is it about time to set a cutoff date for inclusions into TC2, and is it expected there will be a TC3 before Issue 8? | ||||
| Desired Action | At Line 81307, Change "None." to text about current thinking as discussed here, related to general thinking on timetables. If there is a TC3, any firm changes to thinking can be noted then. | ||||
| Tags | tc2-2008 | ||||
|
|
Basing issue 8 on C11 would also have the benefit that C11's memory model could be used to define synchronization and thread safety in detail. (AFAIU, including C11, not C99, in the normative references would also enable similar things.) At least in the glibc community there is currently quite some discussion about what the POSIX definitions actually mean in detail. (This seems to be related to this bug report, so that's why I mention this here. I can create separate reports for the points that are discussed in glibc currently, if that would be better.) |
|
|
Yes, that's the type of thing I was hoping would show up here... The idea of this thread is to discuss those benefits, and pitfalls due to POSIX possibly not being able to make wholesale changes due to backwards compatibility concerns. The large questions are how many aspects have to go through the "being considered 'deprecated' " process before changing to a new type of model or behavior. Here is not for final language of proposals that would warrant separate items, just what are known issues that might affect whether a behavior change is CX of c99, defers to C1x, or neither to guide drafting of language when it's time to get specific. Until then items for Issue 8 are limited to changes that don't rely on any behavior that's changed in C. |
|
|
Change:None. in the FUTURE DIRECTIONS on P2520, L81307 to: Unlike all of the other non-OB-shaded utilities in this standard, a utility by this name probably will not appear in the next revision of this standard. This utility's name is tied to the current revision of the C Standard at the time this standard is approved. Since the C Standard and the this standard are maintained by different organizations on different schedules, we cannot predict what the compiler will be named in the next revision of the standard. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-11-03 11:03 | shware_systems | New Issue | |
| 2013-11-03 11:03 | shware_systems | Name | => Mark Ziegast |
| 2013-11-03 11:03 | shware_systems | Section | => c99 |
| 2013-11-03 11:03 | shware_systems | Page Number | => 2520 |
| 2013-11-03 11:03 | shware_systems | Line Number | => 81306-7 |
| 2013-12-03 21:20 | torvald | Note Added: 0002037 | |
| 2013-12-04 02:24 | shware_systems | Note Added: 0002038 | |
| 2013-12-19 16:29 | Don Cragun | Interp Status | => --- |
| 2013-12-19 16:29 | Don Cragun | Note Added: 0002085 | |
| 2013-12-19 16:29 | Don Cragun | Resolution | Open => Accepted As Marked |
| 2013-12-19 16:29 | Don Cragun | Final Accepted Text | => See 0000784:0002085. |
| 2013-12-19 16:29 | Don Cragun | Status | New => Resolved |
| 2013-12-19 16:29 | Don Cragun | Tag Attached: tc2-2008 | |
| 2013-12-19 16:44 | eblake | Note Edited: 0002085 | |
| 2019-06-10 08:55 | agadmin | Status | Resolved => Closed |
