bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSBundle -initWithPath: warning


From: Richard Frith-Macdonald
Subject: Re: NSBundle -initWithPath: warning
Date: Fri, 01 Apr 2005 11:30:12 +0100

On 2005-04-01 05:13:57 +0100 Sheldon Gill <sheldon@westnet.net.au> wrote:

No ... but I can easily see what the problem is ... '//Local/Library'
looks like a windows UNC path where 'Local' is the host and 'Library' is
the share and the actual file is unspecified ... ie it would be a
relative path on windows.

Absolute path on windows.

So I gathered after much trawling of the web ... I've updated isAbsolute to regard UNC style paths as absolute in all cases.

I've fixed NSString to know that it's an absolute path when running on
unix.

IMHO this is a partial mis-diagnosis of the fault.

Consider the code:
----<begin code> ----

- (id) initWithPath: (NSString*)path
{
  [super init];

  if (!path || [path length] == 0)
    {
      NSLog(@"No path specified for bundle");
      [self dealloc];
      return nil;
    }
  if ([path isAbsolutePath] == NO)
    {
NSLog(@"WARNING: NSBundle -initWithPath: requires absolute path names!");
      path = [[[NSFileManager defaultManager] currentDirectoryPath]
               stringByAppendingPathComponent: path];
    }

  /* Check if we were already initialized for this directory */

-<snip>-

  if (bundle_directory_readable(path) == NO)
    {
NSDebugMLLog(@"NSBundle", @"Could not access path %@ for bundle", path);
      [self dealloc];
      return nil;
    }

---<end code>---

Why is the code checking for an absolute path? It is superfluous and is more likely to cause problems than solve them.

I'm not sure about that ... The NSBundle documentation says this should be a 'full pathname', so it looks like the GNUstep implementation is checking and then trying to be a bit more tolerant than the documentation suggests.

Later on, it checks that the bundle directory is readable. Why?

Because the NSBundle documentation specifies that the intiialiser must return nil if the directory 'doesn't exist or the user doesn't have access to it'

Surely the better option is to simply make the open calls and handle failures properly. That much has to be done anyway. Why complicate matters by doing checks that don't give us any real benefit?

I think they give us the benefit of making sure that the code is MacOS-X compatible.

Consider 1: If the path isn't absolute it may still work in some cases. In the cases it doesn't work, it'll fail to find the file because the path is incorrect. Just like it'd fail if the path was otherwise incorrect.

Yep ... so the current code will work in more cases than if the check and conversion of relative to absolute path was omitted. I think that's a (minor) win for the code as it is. However, I think it's also arguable that we should be less tolerant and fail in all cases where the supplied path is relative ... but only if that's the actual MacOS-X behavior.

Consider 2: if the bundle directory is unreadable, it'll fail when we try to read it. Try to read it and handle not being able to.

Yep ... so it will fail in a place other than that in which it is documented to fail ... so code written by reference to the documentation (eg written for MacOS-X) and testing the results of the init method will go wrong.

Generally, we should try to ensure that methods conform to the letter of the Apple documentation AND match the behavior in MacOS-X ... though occasionally the two actually conflict.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]