Re: GCC 3.0 Branch: Guidelines

[Colm Smyth <Colm dot Smyth at Sun dot COM>]

Hi folks,

I sent this to Mark Mitchell, he suggested just sending direct to the
gcc alias.

Please let me know what you think!

Colm.
------------- Begin Forwarded Message -------------

From: Colm Smyth <colms@ireland.sun.com>
Subject: Re: GCC 3.0 Branch: Guidelines
To: mark@codesourcery.com
Mime-Version: 1.0

Hi Mark,

I noticed your contribution at http://gcc.gnu.org/ml/gcc/2001-02/msg00403.html
and I thought that you might be a good person to contact about
some concerns I have with gcc.

I realize that GCC 3.0 primarily has a responsibility to users of GCC,
but I'd like to suggest some "good citizenship" goals for GCC 3.0 and
I'd welcome your views on whether you think they might be important.

I'd also really appreciate any thoughts you have on how to enter into
a useful discussion with gcc maintainers on these issues.

Basically my suggestions come down to helping code writers to write
syntactically correct code (first priority) and being aware when they
write unportable code (some lesser priority). Since gcc is the tool
of choice for many developers of open-source code but (for many
reasons) some developers prefer to work with platform-specific
compilers, all of which have problems with some of the following:

Some of the most important issues in terms of writing correct code
include (see gcc-syntax.c, gcc-syntax.c.output:

- 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

These are syntax errors that (I think) indicate that you aren't really
sure what you are doing as a code writer; I think the coder should have
to turn on a flag to get the compiler to accept them rather than having
them accepted by default.

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). Using the -pedantic switch will turn on a lot of warnings (some
of which are actually fatal to compiles), but not all of these warnings
are specific to standards-compliance.

Some widely diverging examples of this kind of problem include:

- support of __FUNCTION__ instead of ISO C __func__ 
- macro definitions can include strings with newlines
- 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).
- common use of gcc-specific feature-test macros (e.g. use of __GNUC__ to
  decide if inline keyword is supported).
  
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.

Please let me know how I can best discuss this kind of issues with
the gcc maintainer community.

(by the way, I'm doing this as an individual, not as a designated
"speaker for Sun" and I would treat any e-mail in confidence unless
you tell me otherwise ;)

Best regards,

Colm.
------------- End Forwarded Message -------------

void a_void_function()
{
	return 0;
}

void assign_to_const()
{
	const struct { void *ptr; } x = { 0 };

	x.ptr = 0;
}
% gcc -c gcc-syntax.c
gcc-syntax.c: In function `a_void_function':
gcc-syntax.c:3: warning: `return' with a value, in function returning void
gcc-syntax.c: In function `assign_to_const':
gcc-syntax.c:10: warning: assignment of read-only member `ptr'