Re: NSBundle -initWithPath: warning

[Sheldon Gill]

> 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.

> 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.

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

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?

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.

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.



Regards,
Sheldon