PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Stan Shebs]

Mark Mitchell wrote:

>
>
> --On Monday, August 12, 2002 06:03:10 PM -0700 Stan Shebs 
> <shebs@apple.com> wrote:
>
>> Geoff Keating wrote:
>>
>>  >Typically a #warning from a system header does indicate an error in
>>  >the use of that header.
>>  >
>> That may be the use that you're familiar with, but that's certainly
>> not required by the specification of the construct.
>
>
> Nothing about the problems you're having are new, as I understand it.
> In other words, nothing about the compiler's behavior changed recently,
> right?

That's right.  I would characterize this as an oversight in the original
definition of #warning.

>
> A little up-front experimentation with #warning/-Werror a while back
> would have saved you (in the collective sense) a lot of grief. :-)

Hindsight is always 20/20, eh?  What I believe happened is that there
are some groups within Apple that use #warning a lot; they may even
have it as part of their coding standard.  I just grepped through
public headers in OS X, and there are several hundred of these; private
headers have even more.  We have other groups that require building
with -Werror before their code can go into the system.  This works
fine until the -Werror folks have to add a feature that involves an
API with the #warnings.

Certainly if there were a god of OS X that could come down and smite
engineers until they agreed on everything, this would not be an issue.
But there is literally no way to get this kind of agreement.  Since
there are no other system vendors using GCC on Apple's scale (Cisco
is probably the closest), it's not surprising that this flaw in
#warning seemed unimportant.

> Even less do I see reasons to add a new switch to change the behavior
> of the compiler.  We simply must stop adding a new switch every time
> the compiler doesn't behave the way we want; this constant splitting of
> the proverbial baby by creating switches for me to use and switches
> for you to use makes the compiler bigger and the manual fatter without
> much benefit.

Benefit to who?  GCC is not a painting to hang on the wall and
admire - it's the system compiler for Apple, and if we can't make it
useful for our users, we'll be laid off and Apple will buy a site
license for CodeWarrior or something.  In fact, one of our selling
points vs CW is that we *can* add switches and be responsive to
users.  FSF GCC doesn't really matter to those users as long as
Apple GCC has the features, but we offer them for FSF GCC in the
belief that if they're useful at Apple, they're quite possibly
useful elsewhere.

In response to your philosophical point, while limiting the
functionality of the compiler saves a little work in the short
term, it's not clever in the long term, because you lose all
your customers.

Stan