[PATCH] Windows hang with long filename

[Robinson, Paul]

Forgot to say, please commit for me as I don't have access.
Thanks,
--paulr

From: Michael Spencer [mailto:bigcheesegs at gmail.com]
Sent: Tuesday, March 12, 2013 3:09 PM
To: Robinson, Paul
Cc: llvm-commits at cs.uiuc.edu commits (llvm-commits at cs.uiuc.edu)
Subject: Re: [PATCH] Windows hang with long filename

On Tue, Mar 12, 2013 at 2:33 PM, Robinson, Paul <Paul.Robinson at am.sony.com<mailto:Paul.Robinson at am.sony.com>> wrote:
This is basically the Windows version of r176226; it avoids a
hang when certain issues arise with an output filename.
We found this because Clang would hang because the output file
pathname exceeded the Windows limit of 260 characters.
Yes, I know the context around the fix is about creating the
parent directory; but that's the loop where the hang occurs.

Murphy consequence #1:  I could not find any LLVM tool that used
unique_file(), only Clang uses this AFAICT.  So the test is written
for Clang, which means it has to go in the Clang suite instead of
the LLVM suite.

Murphy consequence #2:  The problem occurs only on Windows, but the
LIT test system apparently has no way to describe a host-specific
test.  Linux and others have different limits on output file paths,
so you cannot expect the same behavior across all hosts.  I was able
to craft a test that did exercise the problem on Windows without
bumping into different problems on Linux, but the only way I could
get it to be cross-platform is to mark it XFAIL: win32, with a big
comment explaining why.

I am resigned to the perverseness of the test.  I'm willing to have
the test accepted on condition that I file a bug against the test
system for being unable to constrain a test based on the host platform.
I'm also willing to have the test rejected as too stupid to live.
(But don't ask me to implement the \\?\ stuff.)

Thanks,
--paulr

Both patches look good. This would actually still be a problem with \\?\.

- Michael Spencer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130312/cabe4e6a/attachment.html>