[LLVMdev] Files to lib/System/Win32

Reid Spencer reid at x10sys.com
Sat Sep 18 12:16:00 PDT 2004


On Sat, 2004-09-18 at 12:01, Jeff Cohen wrote:
> Here's my first take on Path.cpp.  It has a few holes still but it ought
> to be basically functional.
> 
> A few observations:
> 
> First, the Win32 version still has a lot of code in common with Unix. 
> This code should be pulled out into a common file.

truly generic code (common to all platforms) should go in
lib/System/Path.cpp. If you know of such things, feel free to send
patches. FYI: I'll reject anything that has a / in a string literal.
That's not portable to all systems. While it might work on 99.9% of unix
and some modern Win32 machines, it won't work on VMS or OS/390. 

> 
> Second, some of the functions leave me scratching me head.  What purpose
> does create_file serve?  Is there really a need to create empty files?

Yes. Lock files are done this way. However, I'm not sure if LLVM uses
them.

> (It also leaks an open file handle, BTW). 

Oops. I'll take a look.


> I would expect set_file to
> alter only the file name portion of the path and leave the directory
> portion unchanged, and the opposite for set_directory.  set_directory
> obliterates the file name portion of the path (OK, I guess) but set_file
> doesn't make any sense at all.

The Path class is intended to provide path construction, not path
editing. I don't see any need for path editing in LLVM. So, "set_file"
just sets the *entire* path to a single file name. I suppose it could
prefix it with ./ on Unix since that's what it means (i.e. the directory
part is the current directory. Set directory similarly sets the *entire*
path to a single directory name. The various append_* and elide_*
functions assist with path construction, in limited ways.

set_file makes perfect sense ;>

Reid.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040918/f0589913/attachment.sig>


More information about the llvm-dev mailing list