Error C1081 encountered in VS2013 Preview C++ compiler, but not encountered in earlier C++ compilers - by Joseph Miller

Status : 

 


8
0
Sign in
to vote
ID 805360 Comments
Status Closed Workarounds
Type Bug Repros 5
Opened 10/14/2013 12:47:47 PM
Access Restriction Public

Description

I encounter Error C1081 ("file name too long") when building my code with the VS 2013 Preview C++ compiler , but not with earlier compilers (e.g., VS2012, VS2008, etc.).

I have a project that has been configured with "Additional Include Directories". Per MSDN documentation (http://msdn.microsoft.com/en-us/library/73f9s62w(v=vs.120).aspx) the order of locations in which #include directives are resolved is:

1) Directories containing the source files (i.e., relative to the current directory of the file)
2) The "Additional Include Directories", in the order provided
3) [Not Applicable] Directories in the INCLUDE environment variable

When a file tries to #include a file that is included in one of the "Additional Include Directories", the compiler first tries to find the included file at a path relative to the current location of the file. This path doesn't exist, so I expect the compiler to move on to the "Additional Include Directories", where it should find the file in question.

**This works in earlier compilers, even when invoked from VS 2013 Preview (e.g., by setting the Platform Toolset).** However, when trying to resolve the relative path indicated in step (1), the VS 2013 Preview compiler emits a C1081 Error if the resulting relative path exceeds the 260 character limit (even if the path doesn't exist).
Sign in to post a comment.
Posted by Graeme Kelly on 6/2/2014 at 10:39 AM
Hi,

Yes - I can confirm that this issue is fixed in Update 2. Thank you very much!
Posted by Microsoft on 5/30/2014 at 10:41 AM
Hi Graeme,
    We ported the fix back to VS2013 and it should show up in VS2013 Update 2. Please let me know if it fixes your problem.
    (VS Update is not a major release)

Xiang Fan
Visual C++ Team
Posted by Graeme Kelly on 4/29/2014 at 10:22 AM
Hello,

The workaround doesn't really suit all cases, does it? We have quite a structured project and the issue is easily reproducible without having to worry about whether or not the file we are including is from a different project or not.

I have attached a simple test case with a project with one header file, and one source file - VS2013 is unable to include the file that is in the *exact same folder* as the current source file.

The reason for this issue, as you will hopefully see - is that VS2013 appends the entire include path onto the current directory - causing us to reach the character limit a whole lot sooner than we normally would. So if you are in c:\some_folder\one\two\three and you #include "one\two\three\four.h", it attempts to open a file at c:\one\two\three\one\two\three\four.h - normally of course that file wouldn't exist, and it would fall back to the Additional Include Directories, but when the path name is too long, it encounters this error and aborts the entire process.

This hasn't happened in any previous versions that we have used, and it is really causing us a lot of trouble. What is the next major release? Is a VS2013 Update a major release?
Posted by Microsoft on 1/15/2014 at 2:04 PM
Hi edl_si,

We are considering the possibility of shipping the fix in an update, but it is unlikely. In the meantime, please use the workaround described by Joseph in the "Workarounds" tab.

Karl Niu
Visual C++ Team
Posted by edl_si on 1/2/2014 at 9:16 AM
Hi Xiang ,

Is there any chance this fix will go into an update for VS 2013? We have some files in a project that has a big folder structure where the path exceeds 260 characters.

Thanks,
Ed.
Posted by Joseph Miller on 11/25/2013 at 9:02 AM
Hi Xiang,

Thanks for the update!

And I can confirm that the suggested workaround indeed resolves the issue for us.

(On a side note: I've always associated angle brackets in an #include statement with system files - I've never thought of it as being used for any file that isn't part of the project. I think this makes a lot more sense, so I appreciate the help!)

Thanks again,
Joe
Posted by Microsoft on 11/23/2013 at 1:54 PM
Hi:
    A fix for this issue has been checked into the compiler sources. The fix should show up in the next major release of Visual C++.

Xiang Fan
Visual C++ Team
Posted by Microsoft on 11/21/2013 at 5:41 PM
Hi Joseph:
    Thanks for reporting the issue. I can repro it using your project.
    There is an easy workaround, you can make the following change:

#include "a_fairly_looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong_folder_name/another_file.h"

->

#include <a_fairly_looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong_folder_name/another_file.h>

    Does this workaround work for you? This is actually the right way to include a file that doesn't belong to your project. The former will search the current directory of main.cpp which is probably not what you want.
Posted by Joseph Miller on 11/21/2013 at 2:04 PM
This issue is reproducible using the November 2013 CTP (release earlier this week), as well.

I've attached a zip file containing a project that can be used to reproduce this behavior.
Posted by Joseph Miller on 10/21/2013 at 7:01 AM
I've updated the details to indicate this can be reproduced on the released version of VS 2013.

I have also marked the issue as blocking, as it is preventing my team from upgrading to VS 2013. (Or, at the very least, we will have to continue using the November 2012 CTP compiler, if we do.)
Posted by Joseph Miller on 10/21/2013 at 6:54 AM
Just wanted to add that this issue is reproducible in Visual Studio 2013 RTM, as well.
Posted by Microsoft on 10/14/2013 at 10:03 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 10/14/2013 at 12:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)