forums.silverfrost.com

[Sebastian]

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

[LitusSaxonicum]

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

[Sebastian]

[PaulLaidler]

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

[Sebastian]

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

[LitusSaxonicum]

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

[Sebastian]

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.

[IanLambley]

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

[Sebastian]

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.

[PaulLaidler]

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

[Sebastian]

Thanks, this is highly appreciated.

[Sebastian]

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

[PaulLaidler]

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

[Sebastian]

[PaulLaidler]

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