On 24 Feb 2012, at 20:36, Sean McBride <s...@rogue-research.com> wrote:
> On Fri, 24 Feb 2012 10:36:51 -0700, Keary Suska said: > >> I don't believe this is the case. There can be funny issues with BOOL >> types, such that BOOL == YES is an inadvisable construct, since your >> BOOL could be an integer of any value. > > Indeed, and it's extremely frustrating. I encourage you to file bugs on > this, or maybe add a comment here: > > <http://llvm.org/bugs/show_bug.cgi?id=9194> Danger! The code in that bug report is unsafe in another unintended manner too. BOOL isOK = someBitField & someFlag; Is equivalent to signed char isOK = (signed char)(someBitField & someFlag); If someFlag is > 256, the bit that's left set after the '&' is executed will be truncated off by the assign converting down to 8 bits. It's safer to do: BOOL isOK = (someBitField & someFlag) == someFlag; Or simply our controversial friend: if(someBitField & someFlag); Although I'd do: if((someBitField & someFlag) == someFlag) If only to silence compiler warnings about the naked single '&' in the if. Slight tangent: I find the safest way, always, to approach 'if' is not to pretend that it's doing anything other than checking for non-zero values. Once you accept that, lots of 'what's clearer' questions go away, because neither way is 'clearer', they're just more or less verbose. Jamie. [Apologies for formatting, edited on my phone.] _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
