[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