This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Find more ObjC methods


Devang Patel wrote:
> On Oct 7, 2003, at 3:08 AM, David Ayers wrote:
> > So even if this isn't reverted (and I do conceed to the new behavior
> > in the sense that it is /using/ the prototype), I hope a patch that
> > will introduce an optional warning with a more accurate warning would
> > be acceptable.
[snip]
> Now, with this background lets discussion current issue.
> Before Zem's recent patch, GCC had bug in the sense it used to
> warn 'foo may not respond to bar'

The wording was misleading, and could be considered a bug. However, the
presence of a warning was no bug.

> in situations where, it can
> determine that foo responds to bar. So now GCC does not
> issue warnings in such cases. And we are discussing in this
> thread whether we should add new command line option to
> enable 'wrong' compiler warnings.

The warning isn't wrong unless you don't want to follow this convention
(methods declared only in an @implementation are private to that
@implementation).

As David Ayers and I have explained, we find this convention, and the
support from the compiler in adhering to it, useful. If you don't,
you're free to not enable/disable the warning (note "optional").

> I do not approve such patch.

Why? The warning would be optional, so doing this gains you nothing, it
merely prevents those who do want the warning from getting it. It seems
that you want to remove a feature that others use just because you don't
use it, which is not a particularly nice attitude.

- Alexander Malmberg


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]