Re: -fobey-inline (was Re: gcc and inlining)

[Eric Christopher <echristo at redhat dot com>]

> If this seems ridiculous and absolutely unsupportable, then I can only say you
> must not have spent much time in the real world of supplying real compilers to
> real application developers. If you take an adamant "follow-the-standard-or-else"
> point of view, you won't get sued, but you will cut down your customer base.
> 

Only about 6 years, perhaps not long in comparison.

> Finding the right balance between completely ignoring requirements outside the
> standard, and trying to meet every users request for specific undefined behavior
> is not at all easy, but it is part of the job in real world compiler writing.
> 

Of course it is.

> I am not at ALL saying that everytime some C programmer writes carelessly 
> non-compliant code (e.g. assuming that an int is the same length as a pointer)
> should be accomodated with switches or special behavior of the compiler. That
> would indeed be "ridiculous and absolutely unsupportable".
> 

How about C aliasing issues? Those are carefully outlined in the
standard, and yet we've had perhaps thousands of emails on that subject.

> But it is also "ridiculous and absolutely unsupportable" to maintain that a compiler
> has no responsibilities at all for generating reasonable code in some situations
> that are outside the scope of the standard.
> 

"Reasonable" is too vague a word here. Not generating a chess program
into the middle of someone's code is one thing. Ensuring that we can
accurately test (if you support compilers for other people I'm sure
you're familiar with this) for conformance to a particular standard is
far more important than _ensuring_ that someone's broken code behaves
the same way between releases and after every patch. It's a road that no
sane developer would want to go down. Why don't you spend the effort to
get the standard amended if a particular case is important?

-eric

-- 
o/~ got caught stealing fire from the sky o/~