Re: CodeWarrior vs Xcode issues
Re: CodeWarrior vs Xcode issues
- Subject: Re: CodeWarrior vs Xcode issues
- From: Ben <email@hidden>
- Date: Tue, 7 Jun 2005 14:40:06 -0700 (PDT)
You're right, these couldn't hurt anything. But then, neither can:
if (x=y)
... which also throws warnings in gcc, and I'm glad that it does.
On Tue, 7 Jun 2005, Andy O'Meara wrote:
>
>
> > Even if you do manage to suppress specific warnings, how can you
> > differentiate between the "spam" warnings and legitimate warnings if
> > they are the same string? Would you do it on a per-file basis? The
> > real solution, which makes your code also far more portable to other
> > compilers/platforms, is to adhere to the standards. For example, lots
> > of warnings can be squashed using proper casts, comments are not
> > nestable, etc.
> >
> > Personally, if I can't get my code past -Wall (gcc all warnings on),
> > then I don't even bother running the binary- the warnings are a great
> > help to me- even they don't indicate an immediate bug, a proper cast
> > can also double as a supplement to documentation. If I could get a
> > bunch of compilers from different companies for free and compile with
> > all of them with maximum warnings on, I would do it.
> >
>
>
> I absolutely agree--only a fool would turn off warnings like cast
> warnings... As I described, I was strictly referring to two warnings that
> couldn't hurt a flea. Consider an example of one of them:
>
> int n = 'xy';
>
> Correct me if I'm wrong, but I don't see the danger. An ASCII char inline
> like that is equivalent to any other inline integer, so why should I get a
> warning for it? Is there any case that, say, ' ' wouldn't *always* be
> equivalent to 0x2020 or 32 * 256 + 32? Sure enough--try it for yourself:
>
> int n1 = ' '; // warning
> int n2 = 0x2020; // no warning
> int n3 = 8224; // no warning (of course)
>
> Heh, everyone seems to have it in for me just because I say the phrase
> "suppress warnings"--folks just need to see that I'm just proposing that
> Apple improve its warning control/suppression--and that's all....
>
>
> Andy
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden