Mark Wielaard wrote: > On Wed, 2006-03-29 at 09:54 +0100, Gary Benson wrote: > > This patch makes Classpath do the right thing on GNU/Posix systems. > > Cool. But where is the ChangeLog entry!?
Erm, future work? :) > It does look good to me. But in theory the usage of PATH_MAX might > be a problem. According to the glibc manual it might not be defined > if there is no limit on the file name and you should use pathconf() > to get limits in case there are different file systems with > different limits. But then you cannot/shouldn't allocate so much > memory since it might be huge. I don't know if this is a problem in > practice though. Anybody? > > http://www.gnu.org/software/libc/manual/html_node/Limits-for-Files.html > http://www.gnu.org/software/libc/manual/html_node/Pathconf.html We could always use pathconf() and just cap the return value at something we wouldn't mind allocating. I'd need to experiment, though, to make sure it copes with non-existent paths. > Should we cache the result of getCanonicalPath() or isn't it used > that much? It's result should absolutely not be cached. Changes to the filesystem can alter the canonical form of a path. > Could you also add a little note the the NEWS file under > Runtime/Platform interface changes? Ok. > > I haven't committed it as it almost certainly breaks builds on > > Windows, and I need some help to get stuff building conditionally. > > After that I can have a go at porting the Windows canonicalizer > > from GCJ (I don't think Classpath's current one does much on > > Windows). > > No it doesn't. And it is actually pretty platform dependent. The > PlatformHelper.toCanonicalForm() approach didn't really work. IKVM > for example just has its own VMFile.toCanonicalForm() based on > .net/C# System.IO.FileInfo. Your current code should work on cygwin > also which is already nice. Ok, cool. Cheers, Gary
