Re: GCC 3.0 Branch: Guidelines

[Joe Buck <jbuck at synopsys dot COM>]

Colm Smyth writes:
> - gcc only produces a warning when you assign to a const variable
> - gcc only produces a warning when you return a value from a void function

I don't see any reason not to turn these warnings into errors.
For the second one, I can't even see any reason why anyone would
ever not want the condition diagnosed.  So this should be fixed.

> My second category of issues basically applies to all of the gcc extensions
> that aren't in ISO C (and to a lesser extent, some features that have
> come into ISO C, but perhaps not in the same way as they are implemented
> in gcc).

There are two flavors of ISO C, 89 vs 99.  Existing gcc releases
precede the finalization of the new standard, so it cannot be
expected to conform.  But many of the changes between the two
standards are the adoption by ISO of some of the more popular
GNU extensions.  If those extensions weren't there before, ISO
might not now have them.  So gcc need not apologize.

> Some widely diverging examples of this kind of problem include:
> 
> - support of __FUNCTION__ instead of ISO C __func__ 

We can't abandon __FUNCTION__, it is far older than __func__.

> - macro definitions can include strings with newlines

I don't know to what extent this is a problem.  There has been
argument over strings with newlines; they are nice for asm but
perhaps not so useful otherwise.

> - difficulty of distinguishing lint-type warnings from ISO/ANSI C warnings
>   (no specific compiler flag for standards-compliance and no search string
>   that can be used to filter ISO/ANSI-related warnings if -pedantic is
>   used).

Are you asking for a flag that says "be completely silent about all
conforming programs"?  I'm not sure that that would really promote code
quality if no one removed lint-type problems from their code.  And GCC (at
least in snapshots) does have specific flags for checking conformance to
different standards (e.g. c89 vs c99).

> - common use of gcc-specific feature-test macros (e.g. use of __GNUC__ to
>   decide if inline keyword is supported).

In pre-c99 this was necessary.  You could ask the autoconf folks to come
up with better tests, but it'll take years before all the C programmers
learn about this.  "long long" is a similar story; it's supported by
many compilers but not all coders know this.

> Basically my concerns are due to the tremendous success of open-source
> and specifically the gcc compiler suite; because gcc is so ubiquitous,
> it would be great if it helped to support developers who want to stay
> compliant with the language standards or who want to create source that
> can be compiled with platform compilers.

"platform compilers"?  Do you mean "the compiler Sun sells?"

While gcc can be improved in this regard, I could assemble a list of
similar length of issues with Sun's C++ -- many nonstandard coding
practices are accepted by that compiler.  In my company, we have lots of
code developed on that platform that doesn't easily port.  It's a tough
job to get right.

> As a developer, I'd like to do
> this because sometimes the platform-compiler can produce debug information
> that my platform debugger uses to provide better debugging support
> (multi-threading and runtime memory checking).

For Suns, I'd like to have the union of the features provided by dbx and
gdb.  dbx handles multithreading and has a few other nice features, but
has many more restrictions on method calls than gdb does.  For visual
debugging, I like DDD better than the proprietary Sun stuff.

> If I were a release
> engineer, I might do it because a platform-specific compiler can 
> extract the best out of the CPU.

The gcc team's effort would be better spent improving performance, than on
encouraging people to move to proprietary compilers.  And proprietary
compilers (especially for C++) have very large numbers of bugs.  I've
spent years of work making large amounts of C++ code work around all the
compiler bugs in Sun C++, HP aCC, MSVC, and yes, g++.  Release engineers
supporting multiple platforms would be better off just dealing with the
bugs in one C++ front end, rather than many, even if there is a small
performance penalty (performance differences are less than SPEC scores
suggest because of benchmark-specific tuning by proprietary compiler
developers).