write longer string into shorter string

As far as my testing goes it was not related to the compiler version (v5.5 and v6.0 at least did behave the same in this regard, working fine without notice under XP and resulting in the error message box under Win7/x64).

I have tested the original program in this thread under XP

So this adds another twist to the whole thing in that this works fine on a real lot of PCs under XP (we're using it in production code in several places and this error message box was never reported to have occurred), results in an error message box on at least one XP pc as well as some (all?) Win7 (x64 only?) PCs.

but internal write is only an back-handed external write where the 'file' is assumed to be large enough to take the data.

The 'file' is large enough, the write shall transfer 20 characters to a 20 characters-long string variable, or is there anything I'm missing?

Thanks for your testing, and the reports of other people.

I have now tested on Windows 7 64bit OS giving the same runtime error. I am using the latest library (not yet released) but I doubt if that makes a difference.

I am assuming that the WRITE wraps around to repeat the format when it is exhorsted so the 50 characters have no where to go. Maybe the I/O library needs tweeking in this context but I am hoping that you can live with a simple change to your code.

FWIW, I tried compiling and running the code too, since I was intrigued by the apparent differences in runtime behaviour between nominally identical machines. I have an interesting report to make.

My report was going to be:

'I'm using ftn95 v6.00 and I get the same as Paul - with all of /RELEASE, /DEBUG and /CHECKMATE builds, the code builds OK and produces runtime error 89: attempt to write past end of internal file'

Then I remembered that Paul had sent me a trial version of salflibc.dll a couple of weeks ago, to see if it would fix the anomalous SDBG behaviour I reported elsewhere on the forum (it didn't). I couldn't remember whether or not I had reverted to the official v6.00 version. I checked using the Salford diagnostic tool, and sure enough the salflibc.dll in the Windows system directory was the trial version. When I replaced it with the official v6.00 version, all three builds of the code ran without error.

So it looks as though Salford's internal salflibc version control may have got a litttle uncontrolled.

Paul,

I think you should review the unreleased dll, as I think the original code should work, as A20 should effectively truncate LONG to LONG(1:20), which is compatible with the length of SHORT

John

I will pass on your recommendation to the person responsible for this code.

My first thoughts (see above) was that it was not valid. But then reading the posts here my position changed to the point where I thought it must be ok. I confess I haven't had time to look at what the various standards say.

[u:fcdd37610c]Edit[/u:fcdd37610c] : I have now had a look for the Fortran 77 standard X3J3 it says

'13.5.11 A editing. 'If the specified field width w for A output is greater than len , the output field will consist of w-len blanks followed by the len characters from the internal representation. If the specified field width w is less than or equal to len , the output field will consist of the leftmost w characters from the internal representation. '

So the code is valid it seems.

Anyway in the spirit of muddying the waters a bit more, I tried the code with a number of commercial, free, or GPL fortran compilers under Windows and Linux and this is what I found.

Silverfrost - Works (for me and others, but not Paul or with certain salflibc.dll versions)

Absoft Pro Fortran - Works Open64 - Works Intel ifort - Works gfortran - Works g95 - Works solaris studio Fortran - Works HP-UX Fortran 90 compiler - Works

I am happy to use write(short,'(A)') long(1:20) though 😃 David.

I am happy to use write(short,'(A)') long(1:20) though

I am not happy about having to manually find a tricky write() pattern in existing large source code that may trigger random effects on different computers.

Looking at the standards excerpt davidb posted (thanks!) and from the 'other compilers' results which match my experience, the initially posted code seems fine.

I will pass on your recommendation to the person responsible for this code.

I'd be happy about any such additional information that could clear up the situation.

Just to clarify, this is an issue (a potential bug) that is being investigated and hopefully will shorty be resolved.

Has this been resolved? The small test application reportedly behaves correct in ftn95 6.10 (checking that it's fixed in real-world applications is pretty hard since the effects are usually random and non-reproducable, so I'd like to know for sure the problem has been solved).

Hi Sebastian,

Yes the problem was specifically fixed for FTN95 6.10.

From ftn95.enh: Writing more than 32K characters using the 'A' format gave an 'invalid record length' run time error.

Martin

Thanks for reporting back on this.

How is this related to 32K character writing? The source and destination strings in my example were all below 256 bytes. I'm asking because I've gotten the problem again in a bigger application but could not extract it into a small test case this time.

So is this going to be fixed or at least checked? It again turned up in an apmost impossible to debug scenario where changing fully-correct code into still-fully-correct-but-differently-looking code made it work, the only change being a change of name to name(1:transfer_end) where name was a parameter of the WRITE function.

Martin has reported that this has been fixed at FTN95 6.10. Which version are you using?

See my later replies, the small test example is indeed fixed in 6.10, larger programs still exhibit the bug.

That's why I guess that

Writing more than 32K characters using the 'A' format gave an 'invalid record length' run time error.

may have fixed the small example by accident but didn't touch the real problem.