View previous topic :: View next topic |
Author |
Message |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Mar 22, 2017 5:13 pm Post subject: 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 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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Apr 13, 2017 7:11 am Post subject: |
|
|
Sorry. Somehow I missed this post. I have made note that it needs looking at. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Apr 13, 2017 8:37 am Post subject: |
|
|
This has now been fixed. I hope to be able to upload a new set of DLLs later today. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue Apr 18, 2017 12:23 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue Apr 18, 2017 2:13 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed May 03, 2017 11:03 am Post subject: |
|
|
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.
Code: | 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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Wed May 03, 2017 11:21 am Post subject: |
|
|
Dietmar
I was going to take a look at this but the download does not work for me. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed May 03, 2017 11:52 am Post subject: |
|
|
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 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed May 03, 2017 2:09 pm Post subject: |
|
|
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). |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed May 03, 2017 3:21 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed May 03, 2017 5:26 pm Post subject: |
|
|
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.
Last edited by mecej4 on Wed May 03, 2017 7:54 pm; edited 1 time in total |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed May 03, 2017 5:31 pm Post subject: Re: |
|
|
DietmarSiepmann wrote: | 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! |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Wed May 03, 2017 6:59 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|