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
0000784 [1003.1(2013)/Issue7+TC1] Shell and Utilities Editorial Enhancement Request 2013-11-03 11:03 2019-06-10 08:55
Reporter shware_systems View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Mark Ziegast
Organization
User Reference
Section c99
Page Number 2520
Line Number 81306-7
Interp Status ---
Final Accepted Text See Note: 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
Attached Files

- Relationships

-  Notes
(0002037)
torvald (reporter)
2013-12-03 21:20

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.)
(0002038)
shware_systems (reporter)
2013-12-04 02:24

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.
(0002085)
Don Cragun (manager)
2013-12-19 16:29
edited on: 2013-12-19 16:44

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.



- Issue History
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-03 21:20 torvald Issue Monitored: torvald
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 Note: 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


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