View mode: basic / threaded / horizontal-split · Log in · Help
August 21, 2004
_MAX_PATH, etc, in std.c.stdlib??
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.
August 22, 2004
Re: _MAX_PATH, etc, in std.c.stdlib??
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
August 22, 2004
Re: _MAX_PATH, etc, in std.c.stdlib??
"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.
August 22, 2004
Re: _MAX_PATH, etc, in std.c.stdlib??
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
August 22, 2004
Re: _MAX_PATH, etc, in std.c.stdlib??
"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.
August 22, 2004
Re: _MAX_PATH, etc, in std.c.stdlib??
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
August 22, 2004
Re: _MAX_PATH, etc, in std.c.stdlib??
"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
Top | Discussion index | About this forum | D home