Inconsistency readfa@

The programme following reads a file using subroutine readfa@ and produces different results for the 32 and 64 bit executable compiled from it.

Programme Code

      character*1024 data
      character*512 filename
      integer (kind=2) handle,error_code
      integer (kind=3) nbytes_read
      
      filename='MOD1.BNA'
      call openr@(filename,handle,error_code)
      call readfa@(data,handle,nbytes_read,error_code)
      write(*,*) 'data=',data(1:nbytes_read)
      call readfa@(data,handle,nbytes_read,error_code)
      write(*,*) 'data=',data(1:nbytes_read)
      
      end

File Mod1.BNA consists of the two lines following: #003 #001

The 32 bit executable compiled from this code produces the result data=#003 data=#001 as I expect. The 64 bit executable compiled from this code, however, produces the result data=#003 data=001 omitting the character '#'.

Regards, Dietmar

Sorry. Somehow I missed this post. I have made note that it needs looking at.

This has now been fixed. I hope to be able to upload a new set of DLLs later today.

A new set of DLLs is available here...

https://www.dropbox.com/s/xhk4ofgp5g5xcpn/newDLLs6.zip?dl=0

Paul,

I downloaded the new dlls to my ftn95 installation, however, sdbg64 does not work any more with the new dlls (first steping via F8 causes sdbg64 to 'hang').

Moreover, I did not find symbol SECONDS_SINCE_1980 in the new version of salflibc64.dll.

I switched to the previous version of the dlls again and found that sdbg64 was running ok again.

Regards, Dietmar

Dietmar

It is quite possible that the new DLLs are out of step with either FTN95 or SDBG64. So it is always a good idea to take a backup before using the intermediate DLL updates.

SECONDS_SINCE_1980@ is exported in the latest DLL on my machine but I don't recall if this has changed recently.

The problem with READFA@ was that the order of the 'carriage return' and 'line feed' symbols is reversed when changing from 32 bits to 64 bits. So on the basis of this information you may be able to find a temporary work-around.

Paul,

unfortunately there is still another problem occurring with the new dlls as of April 2017. Some characters are still omitted by the programme following when compiled with ftn95 option /64 set.

      character*2048 data
      character*512 filename
      integer (kind=2) handle,error_code
      integer (kind=3) nbytes_read
      
      nbytes_read=0
      filename='TILES.BNA'
      call openr@(filename,handle,error_code)
      
      while (nbytes_read .ne. -1) do
       call readfa@(data,handle,nbytes_read,error_code)
       if (error_code.ne.0) then 
       	write(2,'(A)') 'Error readfa@'
       	call exit(error_code)
       endif
       write(2,'(A)') data(1:nbytes_read)
      enddo
      
      end

The download link http://lima-acoustics.com/un2/readfa_problem.zip points to a zip file containing input file TILES.BNA and output file TILES_OUT.BNA (created by the 64 bit executable created from the source code above and redirecting the output to file TILES_OUT.BNA). Input and output file differ at line 55 for the first time. If doing the same with the corresponding 32 bit executable then input and output file coincide.

Regards, Dietmar

Dietmar

I was going to take a look at this but the download does not work for me.

Paul,

what was the problem with the download? I zipped the file using gzip. However, I do not know if you could download the zip file at all.

Anyway, here is anoher download link containing a zip file in zip format:

http://lima-acoustics.com/un2/readfa_problem2.zip

If you cannot download this new zip file I suggest to send you an email with the new zip file attached to it.

Regards, Dietmar

Dietmar, you left out '2' after 'problem' in the link that you originally posted. With that put back, the link is fine.

This is what I observed with the 64-bit compiler: the first character of each line (other than that of the very first line input) is lost. In SDBG, the variable DATA can be seen with the second character of the input line in position 1.

A small number of lines in the output file are telescoped combinations of adjacent lines in the input file.

By the way, your programs adds an empty line at the end (when nbytes_read is zero, the data list is empty but the WRITE is executed and outputs EOL).

Mecej4,

thanks for the info that the new link works. Character '2' was added intentionally to have both the old and the new link at hand 😃

I think the problem of omitting the first character of each line was solved with the new set of dlls as mentioned above in an entry of Paul.

However, now characters are omitted which are not located at the beginning of a line but somewhere else.

Yes, the output file has an additinal empty line, but with the code sample I only wanted to show that there are serious differences between input file and output file and hence I did not care for maybe an additional line at the end of the output file when I created the code. The major time was spent to extract the problem from some serious misbehaviour of a GUI application which makes use of readfa@ and creates unexpected results in a graphics window which do not occur when using the 32 bit version of the GUI application.

Regards Dietmar

A fix is available here...

https://www.dropbox.com/s/97j3efxmldf2jnw/newDLLs9.zip?dl=0

Sorry, Paul, newdlls9.zip contains a clearwin64.dll with a length of only 1,445,888 bytes (after extraction), and that DLL makes all 64 bit FTN95-compiled EXEs as well as SDBG64 to crash with an Application Error : 'The application was unable to start correctly (0xc0000142)' error. I reverted to the older version, which is 2,384,384 bytes.

The new versions of the other DLLs seem to work fine.

Quoted from DietmarSiepmann Character '2' was added intentionally to have both the old and the new link at hand 😃 Dietmar

Dietmar, someone removed readfa_problem.zip from http://lima-acoustics.com/un2/ . That is why Paul (and I) could not find it!

mecej4

The size of 1,445,888 bytes is correct so it would be interesting to know if other users experience the same problem. The larger size for the existing DLL suggests that it is a debug version of clearwin64.dll which must have been sent out by mistake.

I do have an alternative way to build the release version of clearwin64.dll so we could give that a try.

The bigger DLL is the one that came with the installer http://www.ftn95.co.uk/ftn95/ftn95-8.10/ftn95_personal.exe . It has a time-stamp of Tue Jan 31 03:45:31 2017 (0x58905CBB).

The older DLL exports 1222 symbols, where as the new one exports 1227.

Sorry about the missing link, yes it was removed by a colleage of mine.

Meanwhile I have downloaded the new dlls coming with newdlls9.zip (containing clearwin64.dll of size 1.445.888 Bytes) and found:

1. the latest problem with readfa@ has been fixed and both my test application and my GUI application work as expected 😃
2. I had no problems rebuilding my test app and my GUI app using the new clearwin64.dll (contained in newdlls9.zip)

Regards, Dietmar

In addition to my last post I should say that with the new dlls I cannot use sdbg64 any more. The debugger comes up, but the first step via F8 makes it hang. I mentioned this problem in a previous post as of 18th of April 2017.

Regards, Dietmar

Here is a new set of DLLs. clearwin64.dll has been rebuilt and hopefully will now work with SDBG64 etc.

https://www.dropbox.com/s/6yzkwpcljn2opg2/newDLLs10.zip?dl=0

The 3 DLLs have the same version number when viewed from Windows Explorer (right click on a DLL, select Properties and then Details). The version number is 19.5.4.13.

19 is the year dated from 1998 (2017). 5 is the month May 4 is the date 13 is the hour

Paul,

thanks, for the new dlls and for the information about the version info of the dlls.

Now sdbg64 does not hang any more in my environment 😃

Regards, Dietmar