[LLVMbugs] [Bug 789] NEW: sys::Path enhancements

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Mon May 29 21:26:29 PDT 2006


           Summary: sys::Path enhancements
           Product: libraries
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org

I have been working on some code that will hopefully land in LLVM at some point, and it needs to 
efficiently grovel through the file system.  Here are a few things that libsystem should do that it doesn't 

1. Implement sys::Path::isAbsolute(), which returns true if the path is an absolute path (e.g. on Unix, 
starts with /, on win32, starts with c:\ or \\network\device).
2. Given a directory name and a filename (maybe with a partial directory on it) append them correctly.  
Right now I'm using (dir + "/" + file), which works fine on unix, but sucks on win32. :)
3. GetStatus does not return inode/device ID numbers.  I want to have some way to uniquely identify 
files, even those that are symlinked together.  If the st_dev/st_ino fields of two files match, they are the 
same, but Path::getStatus doesn't expose these.
4. Given a path to a file, strip off the filename and return just the directory.  For "/foo/bar" it should 
return "/foo" for "bar" it should return "." on unix.
5. It would be double plus good to have an interface to enumerate the files in a directory.

In terms of efficiency enhancements, it would be nice if sys::Path cached the status returned by stat, so 
that calls to things like getSize etc, didn't restat for every call.  It would also be nice if MappedFile took 
in a file size argument so that you could map a file (which was previously stat'ed) without having 
MappedFile restat it.  If sys::Path cached the Status info, it would be natural to pass a path to 
MappedFile to make this all transparent.


------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

More information about the llvm-bugs mailing list