Paul Vixie wrote:
>>  But is there any other way out of the GCC Bloat Syndrome?
> 
> sure there is.  look carefully at the collection of command line options
> that it takes to turn gcc into an ansi-only compiler with the few small
> gcc-isms that actually improve object code (like inline functions) and
> then make them into ./configure options for gcc itself.  this will take
> a few weeks of #ifdef'ing the various parts of gcc to avoid compiling
> all the extra bloat (nested function support comes to mind).  you'd get
> a gcc that was 2/3 the size, probably 3/4 the runtime, and no way to
> accidentally depend on some gcc-ism that would make your code unportable.
> 

I use the following arguments to gcc in the hope that it will
help me produce real ANSI C:

   gcc -Wall -Wshadow -ansi -pedantic

I think this removes the ability to inline functions, although
I vaguely recall this being a feature of the new C standard.

 > this would be a very popular move, not just in the *bsd community but 
 > for the entire gcc community.  and it would be less work than reviving
 > pcc or writing something new.

As someone who spends most days coding in C, I would love to see
a stripped down gcc that supports *only* ANSI C, regardless of the
FSF view that this is pedantry (cf. the gcc man page describing the
-pedantic option).

And to those that see compiler extensions as some natural evolution
of the C language, I think it's worth pointing out that computers
aren't human beings. Human languages evolve through so called 'slang'
which may eventually become part of the codified language by
inclusion in dictionaries. Humans, however, can puzzle around curious
slang terms, but computers (or more precisely compilers) don't have
this intuition. So when I take a program written in 'gcc C' and try
to compile it on the native Tru64 or Solaris compiler, it simply
wont build.

The correct approach to language extensions should be an 'opt in'.
Gcc enables its extensions by default, and requires me to add the
-ansi and -pedantic options to produce 'real C'.  It would be better
to have command line options that enabled extensions, clearly
marking code (like the Linux kernel for example) as *not* ANSI
compliant. Then if these extensions prove invaluable, they should
be evaluated at the next C standard meeting.

Chris

-- 
chris.wareham@iosystems.co.uk (work)
cwareham@btinternet.com (home)