discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: attributed string Macro in TalkSoup


From: Riccardo Mottola
Subject: Re: attributed string Macro in TalkSoup
Date: Wed, 11 Sep 2013 01:31:06 +0200
User-agent: Mozilla/5.0 (X11; FreeBSD i386; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1

Hi,

Wolfgang Lux wrote:
Riccardo Mottola wrote:

do you see anything wrong with this macro?

#define S2AS(_x) ( (_x) ? [[[NSAttributedString alloc] initWithString: (_x)] 
autorelease] : nil )

It is then called by passing a string like @"hi".

I added the ternary operator to return nil if nil is passed.

When used in TalkSoup, I get these two errors:

commands.m:368: warning: the address of '_OBJC_INSTANCE_30' will always 
evaluate as 'true'
commands.m: In function '-[TalkSoup(Commands) commandClientinfo:connection:]':
If you look carefully you'll notice that this is a warning and not an error. And the 
compiler is of course right. The condition (_x) expands to (@"hi") and that 
condition always evaluates to true. So the compiler warns you that in this particular 
case the else branch of the conditional can never be reached and thus is redundant (and 
might never be reached by coverage tests).
Aha, I suspected this. It was me that introduced the "test" in the macro because if (_x) wa snil I would get an exception. I created two versions: one to be used with constants (known to be non-nil) and a generic one.

main.m: In function '-[NetclassesConnection 
changeNick:onConnection:withNickname:sender:]':
main.m:418: warning: pointer type mismatch in conditional expression
And this is also a warning and not an error. It's due to a dumb compiler that 
expects you to use then and else branches in a conditional expression that have 
the same type. This is of course the compiler's fault. The compiler should not 
complain if the expression in one branch is a subtype of the expression in the 
other branch. I think this was fixed in either gcc version 4.6 or 4.7.
Perhaps. It was easy to cast it in the macro and silence it, however I have seen popup elswehere in the code and I'll leave it there.

Thank you,

Roccardo

Attachment: riccardo_mottola.vcf
Description: Vcard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]