JTC1/SC22/WG14 N686

                          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.