compiler hangs when using deep directory structure

Hello,

when using a deep directory structure (or a long firstlevel path) ftn95 hangs/crashes in various manners depending on the effective path length when using a multifile-compile (ftn95 *.f95 rather than specifying a single file).

Simple example to reproduce the problem (ftn95 v5.21 up to 5.50): creating a directory on the C: drive with the string 'test1234567890' repeated 9 times (using different nesting and command line parameters this length may be somewhat less in total), means

C:\test1234567890test1234567890test1234567890test1234567890test1234567890test1234567890test1234567890test1234567890test1234567890\

and put a file module.for in there which contains only

module module1
end module module1

and then compiling this with 'ftn95 *.f95', it simply hangs.

Sebastian,

Are you really surprised by this? When using Clearwin, you need to specify a character variable to hold a path, and they always have finite length. FTN95 clearly has a limit (based on your experience and example) shorter than the Windows limit, for example, see the Microsoft MSDN document : http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx - from which it appears that the maximum path is 260 characters (although it says that you can create paths in the *file system *that you can't access with the shell, and that the windows API has yet another limit). There's a further limit at 32k that can be enabled for using Unicode, but I'll bet that FTN95 doesn't.

At a guess, I'd say they set it at 127 or 129 characters. (The example for GET_FILTERED_FILE@ uses 129 characters - and thinking it was the limit, I'd used the same in one of my programs. That falls over too if you exceed the string length).

Eddie

Are you really surprised by this?

Yes I am, I expect the compiler to at least abort the compilation with an error if it can't handle the length, rather than nondeterministic effects like stopping compilation with no output, crashes etc.

As noted this does (and actually did) occur with far less path lengths when compiler options are used.

I will aim to investigate this issue when I get a moment.

Thanks, additionally a case that crashes differently with a shorter path: same configuration as above, path:

C:\test1234567890test1234567890test1234567890test1234567890test1234567890\

and compilation with

ftn95 /colour/implicit_none/full_debug/checkmate/brief/cfpp *.f95

Sebastian,

In the cold light of a new day that first sentence looks as if I intended to be critical of you - it wasn't meant to be. Just that one has a long experience of such things in software - and they cluster around the 'edges' of data structures - usually the 'top edge' because that isn't encountered very often. The quick fix is always to make the data structure a bit bigger, then the 'top edge' is encountered less frequently. It's a lot more effort to handle it properly.

This can't be put more elegantly than in the note by Les Hatton at:

http://www.leshatton.org/Documents/A34.pdf

The different approaches to what happens when you reach the end of a data structure are:

1. Let it happen, and to hell with the user. This also includes generating incomprehensible messages. Most Fortran programs ever written fall in here!
2. Crash elegantly, but nevertheless stop functioning. By elegantly, I mean tell the user comprehensibly what is happening. Mostly, FTN95 fits here - and by design - a compiler can terminate properly as far as its author is concerned if it has emitted an error message, and when it does that you've lost nothing. I agree that this is the minimum that is readily acceptable.
3. Stop you from reaching the limits (the Windows ideal). This is where 'greying out' comes in! (But difficult to do in a console application like FTN95). It does make me wonder how Plato works for your problem.
4. Have no limits. Nirvana!

There is a halfway house between 1 and 2, which is to behave quirkily, but have the limits clearly stated in the documentation somewhere they can be found easily. FTN95.chm and the ENH files don't do that very well.

Eddie

This issue (which makes batch-compilation a pretty random-crash experience) has occurred in several flavours now, a colleague noted that it has even worse effects on Windows 7.

In a network environment, path names become quite long. You can map a long path to a drive letter and then try again refering to the drive letter instead. This should show whether it is the string length. Ian

The path name was not very long on the last occurrences of this bug, and moving it down one directory level was enough to make the compiling progress normally (otherwise there was a 'can't find file' message on a *.f95 call which can't happen). The very-long-path-name thing I've posted is a means of reliably producing a bug on all tested systems which is why I've posted it in that form back then.

I have located the bug and will fix it for the next release.

Thanks, this is highly appreciated.

Follow-up on the problem of compiling in a 'ftn95 *.f95' fashion, the following may be a Win7-only problem:

Create a directory C:\testdirect12345678901234567890 Place a dummy file named testfile901234567890.f95 in there (can be as simple as a single empty subroutine) Then compile using ftn95 /colour/implicit_none/full_debug/bounds_check/CFPP/VPARAM Debug 9 *.f95 in that directory, results in a strange

*** /NT_MULTIPLE_COMPILAT◘´═ is not a valid option on the command line - use FTN95 /? for valid options

It works completely fine if replacing the *.f95 by the actual file name.

What happens if you change to backslash and put in the missing backslash before the *.

What happens if you change to backslash

Change what to backslash? The / parameter slashes??

and put in the missing backslash before the *.

There's no backslash missing, the .f95 is used to compile all f95 files in the directory, the only thing to replace this with would be .\.f95 which is exactly the same as *.f95. I'll try that if this is what you mean (just adding a backslash would/should look in the root directory).

OK I now understand what you are doing. Try putting the *.f95 after FTN95, i.e. the first item in the list.

This does not change a thing, so doesn't replacing the .f95 with .\.f95

When using /checkmate instead of /bounds_check the error message is different but strange in a similar way:

*** More than one source file specified with names C:\testdirect12345678901234567890\testfile901234567890.f95 and ´═♥hðñ

Now some testing under XP: there's a similar error with a larger parameter list, namely I was using '/VPARAM Debug 123456789' for testing which leads to an exception message box during compilation:

004ed118 exe_process(<ptr><ptr>constÄchar)#52 [+0058] 004ed2b4 do_nt_multiple_compilations(<ptr>char,<ptr><ptr>char,<ptr><ptr>char)#52 [+00d4] 004f104b ProcessCommandLine(<ptr><ptr>char) [+0a68] 00401000 main [+0357]

Again depending on how long the directories/parameter strings are, the failure messages or exceptions vary.

To shorten your command, you could try putting compiler options in ftn95.cfg, either globally with ftn95.exe or locallly in the project folder. Also Map Network Drive in Explorer>Tools may be a way of shortening the path. I'm only familiar with XP so don't know if this would work on 7.

John

you could try putting compiler options in ftn95.cfg, either globally with ftn95.exe or locallly in the project folder.

This makes the various batch compilation types very hard to realise, also some files are compiled with different VPARAM and other settings.

Also Map Network Drive in Explorer>Tools may be a way of shortening the path.

I'm already doing compilation of most of the stuff in the root directory because of the compiler errors.

I have now fixed the bug relating to the unexpected option /NT_MULTIPLE_COMPILAT...