Crash chuzzling an NSBigMutableString

[tgaul]

We encountered a crash in ChuzzleKit (as used by PromiseKit) when URL encoding a string that came out of a text field. The issue here is that for performance reasons, UIKit hands out a pointer to the internal mutable string representation (which can be an NSBigMutableString for long strings) and we were handing that to PromiseKit.

To fix this in our app, we made an immutable copy of the string we get from the text field and use that to call PromiseKit.

However, it would be best if PromiseKit didn't cause a crash if someone does this.

The 'crash' is the following exception at line 16 of Chuzzle.m (the mutable string copy line [(id)self setString:s];):

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', 
reason: 'Attempt to mutate immutable object with replaceCharactersInRange:withString:'

You'd think an NSBigMutableString would be mutable based on its name, but apparently not in all cases (at least you can't always call setString: on it without this happening).

[mxcl]

Hmm. I guess we could call mutableCopy in the mutable path. Hah.

Otherwise we can remove the mutable paths. They aren't important IMO. They were added in a pull request.

I've tested this kind of thing with mutableArray, and IIRC the objects respond to the mutable selectors, but they crash if you call them, so it's a strange area of objc.

Since we are categories we can't have a category for NSString and NSMutableString, or at least, in my testing, this did not work, hence the strange checks for mutability in the methods we have.

I'm leaning towards removing the mutability parts, I think it is not possible to properly support them.

[mxcl]

Also, you didn't want the textField’s string to be chuzzled anyway! I'm not sure if we should consider this ChuzzleKit’s fault or UIKit’s though.

Still I feel sticking with immutability is what I intended for this library, and what people expect.

[tgaul]

Yeah, I hadn't realized it returned a pointer to it's representation string, so I fixed that in our code by making an immutable copy. It's something I'll be sure to remember in the future when using UITextView.

I think ideally chuzzle would avoid mutating objects in place, as that would seem to be safest.

I'm personally not sure about how it does whitespace trimming either. What's happening in my case is the string that's a URL parameter was a user-entered value in a text field. It turns out that I do my own whitespaces trimming, but who's to say that some app doesn't want to include spaces or newlines or tabs at the beginning/end of the string it's passing as a URL parameter?