Problem matching $ (end of string)

[Doug Dickinson]

With a pattern of $, rangeOfRegex: says it is not found.  Here are some tests to try:

  NSString *subject = @"foo";
  NSRange r = NSMakeRange(NSNotFound, 0);
 
  STAssertNoThrow((r = [subject rangeOfRegex:@"^"]), NULL);
  STAssertTrue((r.location == 0 && r.length == 0), @"Range: %@", NSStringFromRange(r));
 
  STAssertNoThrow((r = [subject rangeOfRegex:@"$"]), NULL);
  STAssertTrue((r.location == [subject length] && r.length == 0), @"Range: %@", NSStringFromRange(r));
 
  STAssertNoThrow((newString = [@"bar" stringByMatching:@"^" replace:1 withReferenceString:@"foo"]), NULL);
  STAssertNotNil(newString, NULL);
  STAssertTrue(([newString isEqualToString:@"foobar"] == YES), @"String: %@", newString);
 
  STAssertNoThrow((newString = [@"foo" stringByMatching:@"$" replace:1 withReferenceString:@"bar"]), NULL);
  STAssertNotNil(newString, NULL);
  STAssertTrue(([newString isEqualToString:@"foobar"] == YES), @"String: %@", newString);
 
Although it doesn't match (using rangeOfRegex:), it does do a replace (using stringByMatching:replace:withReferenceString:).  I chucked in a "fix" which fixes the problem for me; in RegexKitPrivate.h, change:

#define RKRangeInsideRange(inside, within)            (((inside.location - within.location) < within.length) && ((NSMaxRange(inside) - within.location) <= within.length))

to:

#define RKRangeInsideRange(inside, within)            (((inside.location - within.location) <= within.length) && ((NSMaxRange(inside) - within.location) <= within.length))

Regards
Doug Dickinson --dd

[John Engelhart]

Doug,

Thanks for the bug report and fix.  I've checked in your change, along with updates to the unit tests to verify everything works as intended.  I expanded on your test by including several Unicode permutations to ensure unicode strings are handled correctly as well, along with "^." and ".$" tests (and the unicode permutations as well).

I figured the ^. and .$ tests are just as tricky, and the conversions back and forth between PCRE's UTF8 and Foundations UTF16 representation of 'range' values always raises the possibility of something creeping in.