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

Thomas Schwinge thomas at codesourcery.com
Mon Mar 25 16:13:50 PDT 2013


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.)


Grüße,
 Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130326/41ce56c4/attachment.sig>


More information about the cfe-commits mailing list