Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Were GNU C extensions proposed for the standard?
Keywords: ANSI, GNU, typeof, inline, alignof
Message-ID: <15714@haddock.ima.isc.com>
Date: 21 Jan 90 20:26:10 GMT
References: <153@dy4.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 29

In article <153@dy4.UUCP> paul@dy4.UUCP (Paul Burry) writes:
>I was wondering if any of the other GNU C extensions were proposed as new
>features in ANSI C.

Yes, I'm pretty sure that several-to-most of those you list were proposed.

>If these extensions were proposed, what was the justification for denying
>their inclusion in the standard?

They haven't been tested yet.  The right way to standardize these experimental
features is to make them non-standard extensions to a compiler, let them get
good exposure, and then submit them as proposals for the *next* standard.
Their presence in gcc makes them candidates for C99, not C89.

>[e.g.] allowing expressions, compound expressions and casts as lvalues.

I can't think of any useful semantics for |(a+b)=c|, and I don't believe that
the feature exploited by |*((int *)charptr)++| is well-defined when you get
away from vaxlike architectures (even assuming that |charptr| is known to be
properly aligned).

>(on a side note, why didn't ANSI C define a way to avoid shadowing external
>variables in a macro defining?)

I believe the Committee thought (as I do) that extending the preprocessor in
that direction is a dead end, since inline functions provide a much cleaner
and more powerful way to do most of the same tasks.

Karl W. Z. Heuer (karl@haddock.isc.com or ima!haddock!karl), The Walking Lint