mikeash.com pyblog/friday-qa-2012-12-14-objective-c-pitfalls.html comments

ihar - 2017-08-23 20:06:17

Wed, 23 Aug 2017 20:06:17 GMT

Nowadays on 64bit IOS BOOL is _Bool and not signed char.
So,



if (someObject) {

}

is not a problem anymore.
https://stackoverflow.com/questions/31267325/bool-with-64-bit-on-ios/31267502

Safewiper - 2014-11-13 01:01:34

Thu, 13 Nov 2014 01:01:34 GMT

As a programmer familiar with C++, Java and Objective-C, I have to say OC seem much easier than the other two from the experience of novice developer. It's great to read in-depth analysis like this one.

Ben - 2013-01-23 18:31:02

Wed, 23 Jan 2013 18:31:02 GMT

@Stephen - I assumed he left the initialization out for brevity (since it may be an ivar, extern, static, etc.) and was simply providing us the type.

It might be the case that result pointer will be garbage, but it might also be nil depending on how it is defined, luck, what type of build, etc.

This is the problem with pseudocode, there can be a number of "issues" that aren't really issues at all depending on if we have all the context or not. So we are all simultaneously correct and incorrect :)

Mark Aufflick - 2013-01-16 04:42:04

Wed, 16 Jan 2013 04:42:04 GMT

Of course, if you happened to have a method called "isNotEqualTo:" then the behaviour would be problematic, and a good reason not to have a method that operates that way around!

Mark Aufflick - 2013-01-16 04:40:20

Wed, 16 Jan 2013 04:40:20 GMT

I would say that:

[nil isEqual: nil] == NO

Is in fact exactly what I would expect, equating nil with an SQL-like concept of no/null value, and that a null value cannot equal anything, not even another null value.

Sean M - 2013-01-04 15:44:04

Fri, 04 Jan 2013 15:44:04 GMT

Stephen, under ARC, "NSMutableArray *result" doesn't give a pointer filled with a garbage address, it is initialized to nil.

Stephen Lottermoser - 2013-01-04 00:32:40

Fri, 04 Jan 2013 00:32:40 GMT

@Ben Isn't @MWS's real problem that he forgot to initialize the result array? NSMutableArray *result; would give a pointer filled with garbage instead of a valid mutable array object, so adding objects to it and the returning an autoreleased object would fail and most likely crash the app.

Ben - 2012-12-28 05:05:44

Fri, 28 Dec 2012 05:05:44 GMT

@MWS - Technically you are returning an autoreleased array, not an empty one. If the method that called this one retains the array then it will not be collected when the run loop executes next (or whenever the containing autorelease pool is drained).

jamie - 2012-12-23 18:22:00

Sun, 23 Dec 2012 18:22:00 GMT

Is it possible to write your own user-created static checks rules for Clang/LLVM, without going down into the source or writing a plugin? Something simple like TDK's -- "never allow a function to return a __block type" or some such.

Sean M - 2012-12-22 02:03:28

Sat, 22 Dec 2012 02:03:28 GMT

The fact that BOOL has 256 values is maddening. Regarding this, I would also suggest one never compare BOOL variables against YES. ie:

BOOL foo = ComputeSomething()
if (foo == YES)
...

Hopefully clang will warn on this one day: <http://llvm.org/PR9194>;. Until then, at least searching your codebase for "== YES" is not so hard.

mikeash - 2012-12-19 23:53:44

Wed, 19 Dec 2012 23:53:44 GMT

John Brewer: This is definitely something that happens, as running into it recently is what prompted me to add it to this list. It looks like it's configurable, and since it's global state, you can't rely on it being set to anything in particular unless you own everything in your process.

John Brewer - 2012-12-19 12:23:15

Wed, 19 Dec 2012 12:23:15 GMT

Is EINTR handling an issue on iOS and modern MacOS? I was under the impression that BSD handled retries on signals automagically.

TDK - 2012-12-17 21:55:03

Mon, 17 Dec 2012 21:55:03 GMT

Threaded code pitfalls should be an article all of its own, but here's one Objective-C makes trivial to typo or misunderstand.



- (NSString *)newString {

    __block NSString *returnString = nil;

    dispatch_async(dispatch_get_main_queue(), ^{

        returnString = [[NSString alloc] initWithFormat:@"Expensive String"];

    });

    return returnString;

}

- When does -newString return? Almost immediately.
- When does returnString get initialized? Um, whenever.
- When does returnString get released? WAT

mikeash - 2012-12-16 01:53:10

Sun, 16 Dec 2012 01:53:10 GMT

Raphael: Object allocation is cheap. You have to allocate memory for the UTF-8 string regardless, so it's probably not much more. For if(object), it's fine. That's equivalent to != 0 which is the same as != NULL.

Grigory Entin - 2012-12-15 23:35:40

Sat, 15 Dec 2012 23:35:40 GMT

I do believe that at least the latest versions of clang are able to complain about (BOOL)object. It does not look like a problem to me.



error: cast from pointer to smaller type 'BOOL' (aka 'signed char') loses information

        BOOL x = (BOOL)object;

Raphael - 2012-12-15 12:01:40

Sat, 15 Dec 2012 12:01:40 GMT

@mikeash: Yeah, I saw -dataUsingEncoding as well. How much overhead is there to using the NSData wrapper?

Also, regarding the “casting objects to BOOL” issue: does this pitfall still hold true when doing something like if(object) {…? I gather C uses int for the comparison happening in the if. What if pointers were longer than the standard int type, would that be a problem then? Are there any platforms where this is the case?

Greg Parker - 2012-12-15 09:15:37

Sat, 15 Dec 2012 09:15:37 GMT

Recent versions of clang warn about that "missing method argument" example. If you really want an unnamed method argument then the compiler will insist that you add some whitespace.

Rob Mayoff - 2012-12-14 22:20:25

Fri, 14 Dec 2012 22:20:25 GMT

Some methods in Cocoa only work reliably for BOOL values of 0 and 1. See http://stackoverflow.com/questions/13750370/button-set-selected-via-bool/13750834#13750834 . So even if you get lucky and your pointer gets clipped to a non-zero value, it may still be treated incorrectly later.

Jeff Johnson - 2012-12-14 19:10:30

Fri, 14 Dec 2012 19:10:30 GMT

Actually, -isEqual: is documented as accepting nil, although unfortunately that documentation is not in the NSObject protocol reference. "However, for backward compatibility, isEqual: methods of the Cocoa frameworks do accept nil, returning NO."
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html#//apple_ref/doc/uid/TP40002974-CH4-SW61

BDB - 2012-12-14 18:41:12

Fri, 14 Dec 2012 18:41:12 GMT

A note: your solution for EINTR could cause some oddities if a signal handler is blocking SIGTERM, SIGQUIT, etc to do cleanup.

E.G. If you are in a loop reading/writing gigs of data your app could stay alive well past the intended short cleanup delay. You'd have to watch a flag set by the signal handler to exit the I/O loop for a complete solution.

mikeash - 2012-12-14 17:05:06

Fri, 14 Dec 2012 17:05:06 GMT

Raphael: This is what the -dataUsingEncoding: method is for. It gives you a NSData object which encapsulates both the bytes and the length.

bealex: The problem only happens if you write i >= 0, and any decent C compiler will warn you that the comparison is always true if you have warnings turned up to decent levels.

bealex - 2012-12-14 17:02:00

Fri, 14 Dec 2012 17:02:00 GMT

I personally hate unsigned ints in length and count. (Yes, I know, I'm from Java world, but does that matter?) Every now and then I create some loop like "i > 0; i--" and if "i" happens to be unsigned, it blows up with nasty errors.

MWS - 2012-12-14 16:53:07

Fri, 14 Dec 2012 16:53:07 GMT

Here's a nice one that happened to me the other day:



NSMutableArray * result;



[result addObject:someObject]; 

//... add a bunch of objects



return [NSArray arrayWithArray:result];

Which returns an empty array. :(

Raphael - 2012-12-14 15:42:40

Fri, 14 Dec 2012 15:42:40 GMT

What has always bothered me about the - (const char *)UTF8String method of NSString is that it needs to calculate the number of bytes that the string will take in UTF-8 but there is no way to get that information out of there so you need to call strlen, which calculates the same information again, again taking a time of O(n).

A method like - (const char *)UTF8String returnedBytes:(* int)byteCount would be very helpful. You could then rewrite your example as follows:

int byteCount;

const char *cStr = [string UTF8String returnedBytes:&byteCount];

write(fd, cStr, byteCount);