Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!paperboy!curley!meissner
From: meissner@curley.osf.org (Michael Meissner)
Newsgroups: comp.lang.c
Subject: Re: Were GNU C extensions proposed for the standard?
Keywords: ANSI, GNU, typeof, inline, alignof
Message-ID: <2909@paperboy.OSF.ORG>
Date: 22 Jan 90 15:36:57 GMT
References: <153@dy4.UUCP>
Sender: news@OSF.ORG
Reply-To: meissner@curley.osf.org (Michael Meissner)
Organization: Open Software Foundation
Lines: 131

I will try to highlight which things acutally got proposed, and why it
might have been rejected.

In article <153@dy4.UUCP> paul@dy4.UUCP (Paul Burry) writes:
| 
| 	While we're on the subject of useful extensions to C
| (like "typeof"), I was wondering if any of the other GNU C
| extensions were proposed as new features in ANSI C.
| 
| 	Some of GNU C's more useful extensions (IMHO) are:
| 
| o	the addition of the "typeof" keyword

	It was proposed, and rejected on the grounds no new features
	and limited utility.

| o	the addition of the "inline" keyword

	It was proposed, and rejected on the grounds of qualitity of
	implementation (ie, the compiler should be smart enough to
	figure out when to inline).

| o	the addition of the "alignof" keyword

	It was debated, but never proposed, since there was no meeting
	of the minds of the precise details of alignment.  It also
	came up, at a time when the committee was trying to not add
	new features.

| o	statements and declarations inside of expressions
| 	ie.
| 	    #define max(a,b)		\
| 		({			\
| 		    int _a = (a);	\
| 		    int _b = (b);	\
| 		    _a > _b ? _a : _b;	\
| 	        })
| 	(on a side note, why didn't ANSI C define a way to avoid
| 	shadowing external variables in a macro defining?)

	Never proposed.

| o	generalized lvalues 
| 	ie.
| 	    allowing expressions, compound expressions and casts as lvalues.

	Brought up and definitely rejected on the grounds that this
	was a bug in PCC (K&R-1 I believe also outlaws it), and it is
	incredibly non-portable, particularly on some machines (like
	the DG & PR1ME machines with different pointer formats).

| o	arrays of zero length

	The whole area of zero sized items was debated over two
	meetings, and eventually tabled for various reasons.

| o	arrays of variable length
| 	ie.
| 	    some_function(int n)
|             {
| 		char array[n];
| 		    :
| 	    }

	This was not proposed, but it looks like the numerical
	extension committee will go with it, and it will be a likely
	canidate for the next standard.

| o	non-constant initializers allowed for aggregates
| 	ie.
| 	    foo(float f, float g)
| 	    {
| 		float array[2] = { f-g, f+g };
| 	    	    :
| 	    }

	This was proposed when the committee decided to allow
	initializing automatic aggregates.  There were some problems
	pointed out in how to nail down all of the details, also many
	people thought it was too complex to satisfy the need
	(particularly those who would have to implement it).

| o	application of volatile and const to functions
| 	ie.
| 	    volatile functions do not return (like exit(), abort()).
| 	    const functions produce no side effects (like sin()).

	These were not proposed.  I think that towards the end the
	committee became more gunshy of overloading keywords (void
	having three different meanings).

| There are a number of other extensions, but I think that these are the
| most useful.

Scanning the GCC texinfo file, the other extensions are:

  o	Pointer arithmetic on pointers to void and/or functions

	This may have been brought up, and shot down because this
	is non-portable, and the semantics of doing it are questable.

  o	Constructors (creating runtime aggregate expressions)

	I remember some discussion, but I think it was dropped due to
	inadequate support.

  o	Dollar signs in identifiers

	This was rejected, because some systems cannot support $ in
	identifiers, and $ is only of the national characters in ISO
	646, and would need a trigraph to use (yech).

  o	Extended asm, asm labels, & global register variables

	These were never considered, since the committee did not bless
	the 'asm' (or 'fortran' for that matter) extension.

| If these extensions were proposed, what was the justification for denying
| their inclusion in the standard?
| 
| -- 
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Paul Burry 			PHONE:  (613)-596-9911
| UUCP: ...!cognos!dy4!paul	POST:	Dy4 Systems Inc., 21 Fitzgerald Road,
| or    ...!cognos!dy4!seu13!paul	Nepean, Ontario, Canada K2H 9J4


Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so