www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - _MAX_PATH, etc, in std.c.stdlib??

reply "Matthew" <admin.hat stlsoft.dot.org> writes:
This is wrong.

Although some UNIXen do define a fixed maximum path (in the form of PATH_MAX,
btw), many do not. For those, one must
query, at runtime, the pathconf() function.

I'm not sure we even need to know such things in D code, but assuming we do, I
suggest that D does what I do in STLSoft,
which is to provide file_path_buffer classes whose size are notionally
determined at runtime. Whether they are or not
depends on whether PATH_MAX is defined for UNIX, and whether Win9x and/or
dealing with A() form functions on Win32.

Examples of this can be seen in the STLSoft headers unixstl_file_path_buffer.h
and winstl_file_path_buffer.h

Alternatively, if people really want _MAX_PATH, then it should be in a Windows
specific file. But even then, people
should be aware that W functions on Win NT systems can have ~32,000 character
path names.
Aug 21 2004
parent reply Sean Kelly <sean f4.ca> writes:
Matthew wrote:
 Alternatively, if people really want _MAX_PATH, then it should be in a Windows
specific file. But even then, people
 should be aware that W functions on Win NT systems can have ~32,000 character
path names.
Sadly, I think there are Win32 functions that write path info to a char pointer and don't offer string length on write failure. So I think we may be stuck with MAX_PATH. But I agree that it should be in a Windows-specific header. Sean
Aug 21 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cg8q1e$2m0o$1 digitaldaemon.com...
 Matthew wrote:
 Alternatively, if people really want _MAX_PATH, then it should be in a Windows
specific file. But even then, people
 should be aware that W functions on Win NT systems can have ~32,000 character
path names.
Sadly, I think there are Win32 functions that write path info to a char pointer and don't offer string length on write failure. So I think we may be stuck with MAX_PATH. But I agree that it should be in a Windows-specific header.
I don't think you quite get what I mean. It's easy to determine the maximum required size for a path buffer for flavours of either UNIX or Win32. It's just that it has to be a runtime thing. Secondly, regarding _MAX_PATH (et al) itself, if we need to keep it, that's fine, but it should not be in std.c.stdlib precisely because many UNIXen do not have a fixed max.
Aug 21 2004
parent reply Sean Kelly <sean f4.ca> writes:
Matthew wrote:
 "Sean Kelly" <sean f4.ca> wrote in message
news:cg8q1e$2m0o$1 digitaldaemon.com...
 
Matthew wrote:

Alternatively, if people really want _MAX_PATH, then it should be in a Windows
specific file. But even then, people
should be aware that W functions on Win NT systems can have ~32,000 character
path names.
Sadly, I think there are Win32 functions that write path info to a char pointer and don't offer string length on write failure. So I think we may be stuck with MAX_PATH. But I agree that it should be in a Windows-specific header.
I don't think you quite get what I mean. It's easy to determine the maximum required size for a path buffer for flavours of either UNIX or Win32. It's just that it has to be a runtime thing. Secondly, regarding _MAX_PATH (et al) itself, if we need to keep it, that's fine, but it should not be in std.c.stdlib precisely because many UNIXen do not have a fixed max.
Ah gotcha. So what we really need is a function. Though I suppose the ideal solution is just to let the file/path routines sort it out behind the scenes. Sean
Aug 21 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cg8vm1$2pt0$1 digitaldaemon.com...
 Matthew wrote:
 "Sean Kelly" <sean f4.ca> wrote in message
news:cg8q1e$2m0o$1 digitaldaemon.com...

Matthew wrote:

Alternatively, if people really want _MAX_PATH, then it should be in a Windows
specific file. But even then, people
should be aware that W functions on Win NT systems can have ~32,000 character
path names.
Sadly, I think there are Win32 functions that write path info to a char pointer and don't offer string length on write failure. So I think we may be stuck with MAX_PATH. But I agree that it should be in a Windows-specific header.
I don't think you quite get what I mean. It's easy to determine the maximum required size for a path buffer for
flavours
 of either UNIX or Win32. It's just that it has to be a runtime thing.

 Secondly, regarding _MAX_PATH (et al) itself, if we need to keep it, that's
fine, but it should not be in
std.c.stdlib
 precisely because many UNIXen do not have a fixed max.
Ah gotcha. So what we really need is a function. Though I suppose the ideal solution is just to let the file/path routines sort it out behind the scenes.
Most certainly we want any std. path modules to do this in a hidden way. But there will undoubtedly be instances where people will still need/wish to interact with native operating system calls. For those cases, I think it'd be much better if there was something like a char[] allocPathBuffer(); function somewhere in Phobos, within which were abstracted the tests against UNIX/Win32 flavour. It could be roughly something like: version(linux) { extern(C) size_t dmc_path_max_calc(); } char[] allocPathBuffer() { version(Windows) { if(IsWinNT()) { return new char[32000]; } else { return new char[_MAX_PATH]; } } else version(linux) { // Here's where it gets a little messy return new char[dmc_path_max_calc()]; } } For Linux we'd need a C file that is roughly the following: size_t dmc_path_max_calc(void) { #ifdef PATH_MAX return PATH_MAX; #else /* ? PATH_MAX */ return 1 + pathconf("/", _PC_PATH_MAX); #endif /* PATH_MAX */ } There are some slight complications in that you only need 32000 for W() functions. If you intend to use the buffer with A() functions, then it only need to be 260 (_MAX_PATH). Also, I guess we'd want forms for dchar, wchar, etc., but I'll leave that the localisation experts to comment on.
Aug 21 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cg91ur$2r4t$1 digitaldaemon.com>, Matthew says...

            return new char[32000];
Wow! I hope you plan to free this huge swathe of memory afterwards. As you (of course) already know, reducing the array's .length won't free the excess, so if the path turned out to "C:\DMD" then that would be an awful lot of wastage. I know you know what you're doing. I'm just asking. I don't understand why there's a maximum /at all/. I would have expected path-getting functions to just return a string of the right length, but maybe I'm just thinking too optimisticly. Arcane Jill
Aug 21 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cg9ev4$1df$1 digitaldaemon.com...
 In article <cg91ur$2r4t$1 digitaldaemon.com>, Matthew says...

            return new char[32000];
Wow! I hope you plan to free this huge swathe of memory afterwards. As you (of course) already know, reducing the array's .length won't free the excess, so if the path turned out to "C:\DMD" then that would be an awful lot of wastage.
You're quite right that that size of block is a concern, particularly in a GC environment. But that size is what's mandated for L"\\?\" paths in W fns on Win32. Remember that my code was only an exposition. Probably we'd want to have this be an auto-class, that allocated from a specific pool. (Can auto-classes be used as return values? If not, we'd just have a FilePathBuffer class that handled the guff internally.)
 I know you know what you're doing.
In some cases. He he In this case I *know* the following facts: - Win32 maximum path is _MAX_PATH for Win9x boxes, and for A fns on NT - Win32 maximum path is 32000 for WinNT boxes with W fns with the "\\?\" prefix - UNIX maximum path if PATH_MAX is defined is PATH_MAX - UNIX maximum path if PATH_MAX is not defined must be determined at runtime from pathconf() However, the rest is just my interpretation. Since we have at least one OS whose maximum is entirely dynamic (UNIX, !defined(PATH_MAX)), then it seems to me we should provide some kind of common class/component that wraps all this stuff, just the the UNIXSTL/WinSTL classes file_path_buffer do. Someone else may want to look at this differently.
 I'm just asking. I don't understand why
 there's a maximum /at all/.
I don't either. Some OSs do, some don't. I don't know the rationale behind the designs.
 I would have expected path-getting functions to just
 return a string of the right length, but maybe I'm just thinking too
 optimisticly.
Remember, I'm talking about something that people will be using for relatively low-level stuff. For users of std.path, std.recls, etc. they should not have to care about this stuff. But for anyone that wants to call out to OS APIs, it'd be nice if we've covered all this nastiness for them, to same them the bother. btw, I wrote a Path class a few months ago, for possible inclusion into Phobos. It's like the UNIXSTL/WinSTL path classes, and allows one to push/pop bits off it, overloads the "/" operator (an abuse, I know, but I think they do it in Boost also), and is just really helpful when manipulating paths. I'd be interested to hear whether anyone would be interested in it, in which case I'll put it in a non-std package and upload. Cheers Matthew
Aug 21 2004