Re: GCC 3.0 Branch: Guidelines

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Hi Colm,

> - 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 agree these should both be errors.  The first one could always be coded
around with a cast by the programmer if necessary.
 
> - support of __FUNCTION__ instead of ISO C __func__ 

I imagine we should be deprecating __FUNCTION__ with a suitable diagnostic
telling people to use __func__ instead.

> - macro definitions can include strings with newlines

This is deprecated in 3.0, and if I'm still around I hope this will die
in some future, not too distant version of GCC.

More generally, after 3.0 one of the things I would like to get done is
sharing diagnostic code between the now-integrated CPP and the front ends.
As part of that, I'd like to provide a more fine-grained separation of
diagnostic types; at present we have little more than Pedwarn, Warn, Error
and Ice.

> 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. 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). If I were a release
> engineer, I might do it because a platform-specific compiler can 
> extract the best out of the CPU.
 
This sounds like it is coming from the agony of someone whose job it
was to get Glibc to work with Sun's C compiler!

I echo Joe's comments in this area.

Neil.