> On Oct 11, 2015, at 23:28, Christiaan Hofman <cmhof...@gmail.com> wrote:
> 
> 
>> On Oct 11, 2015, at 23:23, Adam R. Maxwell <amaxw...@me.com 
>> <mailto:amaxw...@me.com>> wrote:
>> 
>> 
>>> On Oct 11, 2015, at 14:10 , Christiaan Hofman <cmhof...@gmail.com 
>>> <mailto:cmhof...@gmail.com>> wrote:
>>> 
>>> I handled those by adding dummy arguments, either a variable with a nil 
>>> value, or a dummy object (like an empty notification in this case).
>> 
>> I had a few where that wasn't possible, or creating a dummy object might 
>> have side effects that aren't clear. It looks like they just added nonnull 
>> without actually auditing anything.
>> 
>>> 
>>> The one place where I needed the pragma’s was with the -init for the 
>>> operation(queue) class clusters in the file view project.
>>> 
>>>> Adding WARNING_CFLAGS = -Wno-tautological-pointer-compare to FileView 
>>>> helped, too.
>>>> 
>>> 
>>> Where does that have an effect?
>> 
>> My version of it has some checks for functions, like this:
>> 
>> NULL == dispatch_async_f
>> 
>> IIRC clang says to use address-of before the function, but then it complains 
>> about that, too. This style was an Apple recommendation for weakly-linked 
>> functions last I checked, and it's worked for years, just like all the nil 
>> arguments. I'm pretty unhappy with clang and its warnings; somebody at Apple 
>> likes C++ too much.
>> 
>> — adam
> 
> Ah, yes, I added the & for those, and that seemed to do the trick for me.
> 
> Christiaan
> 


BTW, did you add the recommended bundle ID build setting? That did not work 
well for me. When I do that, the defaults command cannot make the connection 
between app name and preference (through bundle ID) anymore. It thinks the 
bundle ID is literally ${PRODUCT_BUNDLE_IDENTIFIER}. Somehow nobody seems to 
see this, but for me it’s very consistent and very reproducible.

Christiaan

------------------------------------------------------------------------------
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop

Reply via email to