Document Number: WG14 N686/X3J11 __-___ C9X Revision Proposal ===================== Title: Obsolescent Features of the C Standard_______________ Author: Peter Seebach_______________________________________ Author Affiliation: ________________________________________ Postal Address: 3949 Lyndale Avenue South, Minneapolis MN 55409 E-mail Address: seebs@solon.com_____________________________ Telephone Number: +1 612-824-6045___________________________ Fax Number: ________________________________________________ Sponsor: Peter Seebach______________________________________ Date: 1997-05-17____________________________________________ Proposal Category: __ Editorial change/non-normative contribution __ Correction __ New feature __ Addition to obsolescent feature list __ Addition to Future Directions Y_ Other (please specify) Removal of old features_______ Area of Standard Affected: __ Environment Y_ Language __ Preprocessor __ Library __ Macro/typedef/tag name Y_ Function __ Header __ Other (please specify) ______________________________ Prior Art: Various, including GNU C_________________________ Target Audience: Anyone not still living in the 80's________ ____________________________________________________________ ____________________________________________________________ Related Documents (if any): ________________________________ ____________________________________________________________ ____________________________________________________________ Proposal Attached: Y_ Yes __ No, but what's your interest? Abstract: C89 declared several items to be "obsolescent features"; these features were slated for removal in future versions of the C standard. This paper proposes ways of removing them. Proposal: There are several separate obsolescent features to be looked at. I will use the C9X draft 9 numbering, which is off by one from the C89 numbering. 6.9.2: I don't show a vote taken on this, so I'm ignoring it. 6.9.5: The straw vote was 7 to implement or remove this, 5 to leave it alone, and 5 abstentions. There are at least three ways to handle this: 1. Remove paragraph 6.9.5. This is the simplest. 2. Implement this restriction, by adding wording rendering the use of two array-declared parameters for the same object undefined. 3. In 6.7.1, paragraph 9, replace shall be adjusted to ``pointer to type,'' with shall be adjusted to ``restrict-qualified pointer ot type,'' so that the rule is enforced for us. I have heard that the Borland C compiler already implements something equivalent to the 2nd or 3rd suggestion. (It also doesn't realize that the adjustment to pointer type implies that a parameter declared as an array is actually a pointer which can be modified; rather, it treats them as normal arrays.) The third provides a convenient way for compilers which are using restrict for optimization purposes to be compatible with code that may need to run on older machines. Any code which is affected by this is, as far as I can tell, already covered by the obsolescent feature list, and any code using this idiom would be guaranteed to work as expected on C89 compilers. 6.9.3 and 6.9.4: These are really very deeply tied. I've gotten a lot of feedback from the user community, and the general impression I've gotten is that old-style definitions are very popular, but no one will miss old-style declarations. The old-style definitions are popular because they allow for convenient grouping of parameters of like type, and make it easier to break function definitions up into easily parsed lines, while keeping the names of arguments all together and in order. Option 1: Removing all compatibility with old-style declarations and definitions is not very hard. It will break a sizeable body of existing code, but there has been plenty of warning, and real compilers will not stop having 'traditional' modes in this decade. Option 2: Another alternative, and one for which there is prior art, is to suppress the usual argument promotions when a prototype for the function is already in scope. This does not change the behavior of K&R code at all, and affects the behavior of no C89 program which does not invoke undefined behavior. Option 3: Yet another is to simply eliminate the usual argument promotions entirely, and allow the old-style definitions as an alternative way to format a prototyped definition. The first option is probably the simplest, the second is probably the most convenient for users, and is the only one for which I have seen any existing practice, and the third is probably the most internally consistent but still convenient for users. NetBSD, and also at least one of the other *BSD's, has a ~150 megabyte source tree which is currently using option 2; all functions are prototyped, but old-style definitions are used for almost everything. This appears to be compatible with K&R systems, and also usable for the GNU C compiler. The language extension used appears to suppress the default promotions only when a prototype is in scope. To implement option 1, we would remove the paragraphs describing the obsolescent feature, and simply remove the majority of the text describing interactions between identifier-list and parameter-type-list function declarations. To implement option 3, we would remove all of the rules for the default promotions. To implement option two, we would have to add some clever wording in the paragraph about identifier-list vs. parameter-type-list function declarations.