Re: named warnings & individual warning control

[Zack Weinberg <zack at codesourcery dot com>]

Mark Mitchell <mark@codesourcery.com> writes:
[snip]
> Arguably, GCC's behavior is not what people want anyhow; a change to
> the implementation of "f" will cause the code above to become
> unsafe.  If "f" is a library function, for example, you really
> wanted the compiler to check your code without looking inside "f";
> you don't want to depend on it not changing in some way.  If you
> really want the GCC-style "what actually happens with optimization
> turned on", you use Purify/Valgrind or a compiler that inserts
> additional checks (ala mudflap).  The logical extension of GCC's
> "I'm taking into optimization into account" point of view is "only
> tell me about functions that I actually run", which is why you want
> to instrument the code, not have the compiler optimizer issue
> warnings.

It occurs to me that the Java spec has definite rules for what
constructs are and are not to receive uninitialized-variable
diagnostics.  Maybe it makes sense to adopt those for cross-language
use? 

A related problem which we currently don't handle at all (except via
inlining): 

void foo(int *out_parameter) { ... }
int bar(void)
{
  int x;
  foo (&x);
  return x;
}

Whether or not there's a use of an indeterminate value in this code
depends entirely on what's hiding in { ... }, but currently gcc just
assumes that foo will write to x.  Unless foo gets inlined.  It would
be nice to be able to diagnose "out" parameters that aren't written on
every control path through foo, and "in" parameters that aren't
initialized before the call.  For C we'd need some attributes to
annotate parameters with so that gcc knew what was going on.

zw