[PATCH] Avoid using the PATH_MAX constant, which may be undefined.

[Sean Silva]

On Mon, Mar 25, 2013 at 7:13 PM, Thomas Schwinge <thomas at codesourcery.com>wrote:

> Hi!
>
> On Mon, 25 Mar 2013 15:51:10 -0400, Sean Silva <silvas at purdue.edu> wrote:
> > We generally try to avoid putting platform-specific #ifdef's in the core
> > code, and instead prefer to keep it in libSupport. It would be great if
> you
> > pulled this code into libSupport by implementing FileSystem.h's function
> > `error_code canonicalize(const Twine &path, SmallVectorImpl<char>
> > &result);` and addressed the nearby FIXME.
>
> OK, that makes sense -- also in context of the LLVM patch
> <
> http://news.gmane.org/find-root.php?message_id=%3C1364227290-13977-1-git-send-email-thomas%40codesourcery.com%3E
> >
> that can then (partly) be rewritten to use this function, too.
>
> What would be the convention to indicate that a host system does have
> non-canonical paths (Unix) or does not (Windows)?
> FileManager::getCanonicalName would use this information to enable usage
> of CanonicalDirNames (currently based on LLVM_ON_UNIX being defined) --
> on the other hand, has this caching of canonical names actually been
> profiled to be of any real benefit?  (Perhaps in cases where network
> filesystem and similar "extravagances" are involved, though, I would
> expect the operating system to cache expansions of symbolic links in such
> cases.)
>
>
>
It's probably enough to just call canonicalize() unconditionally, and add a
comment to the declaration of canonicalize() that it may be a noop if no
such concept exists on the host.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130325/7f463293/attachment.html>