Le jeudi 06 décembre 2007 à 10:59 +0000, Richard Frith-Macdonald a écrit : > On 2007-12-06 09:51:35 +0000 Philippe Roussel <[EMAIL PROTECTED]> wrote: > > Well, I have to disagree : see NSURL.m line 837. I want to type > > http://philou:[EMAIL PROTECTED]/ but when parsing philou: NSURL thinks it's > > a hostname followed by a port and is expecting a numeric value. > > My thought was ... Line 837 of NSURL.m is only reached when checking the port > part of the URL, and since there is no port part in your example string, it > can only be reached from parsing a different URL string. > > However, I just realised that you are probably actually talking about > validating a whole set of URLs as you add a character at a time to the length > ... 'h', then 'ht' then 'htt' then 'http' then 'http:' and so on. > When you get to 'http://philou:' the code will be assuming that 'philou' is a > host name because there is no '@' sign present to tell it that it's actually > a username and password followed by a host. It therefore assumes that what > comes after the colon is a port (and it's correct to do so, because that's > what the RFCs tell us).
Yes, sorry I wasn't clear enough. I'm using this to enable/disable the "Ok" button of a dialog for each modificaton in a TextField. I just didn't find another (easy) way to know if a String is a valid url. I know http://philou: isn't valid and I would like URLWithString: to return nil as documented. > > My code used to function (NSURL URLWithString returning nil with a non > > valid string) until I updated to trunk yesterday or two days ago. > > PS. -initWithString:relativeToURL: should only be exiting with an exception > if you passed it a nil argument. All the other error checking just results > in a nil value returned. This somewhat inconsistent behavior is copying the > MacOS-X implementation behavior (I don't believe an initialisation method > should ever raise an exception). I've modified the logging to refrain from > printing the diagnostics unless debug is explicitly turtned on. > > Anyway, I can't see why any of this should cause a coredump ... perhaps you > could print a stack trace in gdb to show where/why your app is dumping? Here it is (URLWithString is called with @"http://philou:c") : #0 0xb7924c3d in GSPrivateStackAddresses () at NSDebug.m:1145 #1 0xb7938c09 in -[NSException raise] (self=0x857e8c0, _cmd=0xb7b6c548) at NSException.m:817 #2 0xb793876e in +[NSException raise:format:arguments:] (self=0xb7b6c340, _cmd=0xb7b6c530, name=0xb7b6c0e4, format=0xb7b9b11c, argList=0xbfb7a150 "�z9\b\020O3\bH[L\b") at NSException.m:760 #3 0xb79386a6 in +[NSException raise:format:] (self=0xb7b6c340, _cmd=0xb7b9b5d0, name=0xb7b6c0e4, format=0xb7b9b11c) at NSException.m:746 #4 0xb79f26c1 in -[NSURL initWithString:relativeToURL:] (self=0x85197d8, _cmd=0xb7b9b600, aUrlString=0x84c5b48, aBaseUrl=0x0) at NSURL.m:850 #5 0xb79f1bec in -[NSURL initWithString:] (self=0x85197d8, _cmd=0xb7b9b5f8, aUrlString=0x84c5b48) at NSURL.m:619 #6 0xb79f162d in +[NSURL URLWithString:] (self=0xb7b9b580, _cmd=0x8077300, aUrlString=0x84c5b48) at NSURL.m:509 #7 0x0805e3fc in -[iCalStoreDialog controlTextDidChange:] (self=0x847fc10, _cmd=0xb7f29d08, notification=0x849a598) at iCalStore.m:62 #8 0xb796f151 in -[NSNotificationCenter _postAndRelease:] (self=0x80bbe40, _cmd=0xb7b7af08, notification=0x849a598) at NSNotificationCenter.m:1067 #9 0xb796f6d8 in -[NSNotificationCenter postNotificationName:object:userInfo:] (self=0x80bbe40, _cmd=0xb7ec94a8, name=0xb7f46470, object=0x845d180, info=0x82df438) at NSNotificationCenter.m:1126 #10 0xb7cd9da8 in -[NSControl textDidChange:] (self=0x845d180, _cmd=0xb7f29df8, aNotification=0x856cc08) at NSControl.m:567 [snip] It could be something wrong in my code but I haven't changed it in a long time and it used to work fine. Thanks, Philippe _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev