target/6242: linker deletes compiled files

[bob at photowriters dot com]

>Number:         6242
>Category:       target
>Synopsis:       linker deletes compiled files
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 09 19:36:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Bob Wilson
>Release:        gcc version 2.95.2 19991024 (release)
>Organization:
>Environment:
Windows98
>Description:
I wasted three hours late last night trying to compile and run three programs, each of which compiled and ran perfectly after some small corrections to some typing errors. The programs were copied from Sams Teach Yourself C++ in 24 hours, Third Edition by Jesse Liberty. 

So, if they compiled and ran properly, what was the problem? 

In the interest of ease of identification later (i.e., self documentation of a program's purpose), I gave discriptive names to both the project files and the actual programs. 

                          Project File Name                                                           Associated Source File Name
  Passing Function Arguments by Pointer.dev    Passing_Function_Arguments_by_Pointer.cpp*
  Passing Function Arguments by Reference.dev  Passing_Function_Arguments_by_Reference.cpp*
  Passing Function Arguments by Value.dev      Passing_Function_Arguments_by_Value.cpp*

*The underline charcters were used between words rather than spaces because the Bloodshed environment does not allow a C++ program to have the same name as 

However, I was unable to produce more than two .exe files in the same directory, and if I built or compiled the same file twice, the other .exe file would disappear.

When I shortened the names to:

          Project File Name                                           Associated Source File Name
  Passing by Pointer.dev        Passing_Function_Arguments_by_Pointer.cpp
  Passing by Reference.dev      Passing_Function_Arguments_by_Reference.cpp
  Passing by Value.dev          Passing_Function_Arguments_by_Value.cpp

all three compiled and there were three .exe files in the directory. 

        Executable File Name
  Passing by Pointer.exe
  Passing by Reference.exe
  Passing by Value.exe


Earlier, Ioannis Varnos and I had exchanged emails about a problem I experienced with the Bloodshed programming environment, and she had recommended that I stay away from the project creation function of the Bloodshed environment and stick to creating and compiling non project related C++ programs. I discovered that the solution to my problem lay in making direct changes to the undocumented .dev or project file with the notepad, so I continued to work with projects. Eureka! I thought and searched the .dev files for a truncation of my long file names, but they were not truncated in the project files. 

With Ioannis' advice in mind, I closed the project file upon which I was working and brought the .cpp files listed above into the Bloodshed "shell" one at a time and compiled them. The results were the same. I was unable to produce more than two .exe files in the same directory, and if I built or compiled the same file twice, the other .exe file would disappear. 

Although it is not documented, at least I cannot find it, there must be a maximum length of a file name beyond which the compiler/linker combination throws away or disregards the rest of the file name. When the compiler/linker erased a previously existing .exe file of a different name, it always erased the oldest. That leads me to believe that it searches from the top until it finds a file that matches the compiler's target file name, at least to the limits of its file name space, it deletes, and writes a new one, or it overwrites it and changes the name in the file directory. My guess is that the some part of the compiler or linker does not support the full length of windows file names. If this is the case, it is a flaw that should be fixed. Ironically, the names of any .exe file compiled and linked was never truncated. 

Before someone goes on the "yer-files-names-are-too-damn-long" rampage, consider the fact that, unless a compiler is totally compatible with operating system conventions, it is not operating system compliant, and, as such, it is not as versatile or as useful as it could be. Any such limitations or variances should be well documented and internal error trapping routines should provide immediate warnings to the user if he/she exceeds a limit such as the allowed length of the file name allowed by the programming environment which will result in the type of problems documented above. 

I truly hope that someone will send me an email that points out how I either missed the obvious, i.e., the documentation, help screen, option, etc., but I don't hold out much hope of that. I would be interested in knowing any other things like this that others have discovered. 

Regards,

Bob Wilson

>How-To-Repeat:
Change program to Passing_Function_Arguments_by_Pointers.ccp and Passing_Function_Arguments_by_Value.ccp and compile each individually in the same target directory. 
>Fix:
Make it compliant with Windows file names or incorporate the suggested documentation and error trapping routines.

>Release-Note:
>Audit-Trail:
>Unformatted: