forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

write longer string into shorter string
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Feb 18, 2011 12:05 am    Post subject: Reply with quote

I've again tried to test what is happening by identifying the bytes before and after SHORT. Hopefully this code has not shifted the possible problem, but I do not see any overwrite of memory before or after short*20.

I have compiled this code with Ver 5.40 and Ver 5.50 and found no errors.
Still looks ok to me !

John
Code:
! tests write to short by identifying bytes before and after short
!
   character short*20, long*50, cc(-1:22)*1
   equivalence ( short, cc(1) )
!
   cc   = 'x'
   long = '123456789012345678901234567890'
!
   write (*,10) 'Before'
   write (*,11) 'cc    ',cc
   write (*,11) 'short ',short
   write (*,11) 'long  ',long
!
   write (short, '(a20)') long
!
   write (*,10) 'After'
   write (*,11) 'cc    ',cc
   write (*,11) 'short ',short
   write (*,11) 'long  ',long
10 format (/a)
11 format (a,':',25a)
end

subroutine test
   implicit none
   character(len=20) :: short
   character(len=50) :: long

   long = '1234567890'
   write(short, '(a20)') long
end subroutine test
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Mon Feb 21, 2011 3:07 pm    Post subject: Reply with quote

Quote:
Maybe the I/O library could have been written differently or maybe it could be modified but this behavoiur seems natural to me.

The behaviour is anything but natural, it does neither create a crash nor a checkmate exception when running it under XP, and it creates application fault boxes when run under 64bit windows (up to random crashes in a real world application).

Is the code bad? Then checkmate should warn under XP as well. If it is correct (and at the moment I don't see a reason why it should *not* be correct, and other compilers seem to agree on this) then something needs to be done about the behaviour under win7/64bit.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Feb 21, 2011 4:32 pm    Post subject: Reply with quote

I have tested the original program in this thread under XP and all the common compiler modes and I always get a runtime failure... "Attempt to write past the end of internal file".

Sorry but that's the best I can offer unless I have missed the point.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Tue Feb 22, 2011 12:44 am    Post subject: Reply with quote

Paul,

You say "I have tested the original program in this thread under XP" however, I am not getting the results you have indicated.
I have FTN95 Ver 5.40.0 on XP (win32) and Ver 5.50.0 on XP-x64
Both the first code example in this post and my last example compile link and run with no identified problems.
I use first code as file ch_20.f95 then:
ftn95 ch_20 /debug /link
and also tried "/check /link", "/p6 /opt /link" and just /link
then use either "sdbg ch_20" or "ch_20"

I can not get an identified or reported error. Is this a regression applied in Ver 6.0 ?

John
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Tue Feb 22, 2011 2:52 am    Post subject: Reply with quote

It works for me with no problems as well. I am using version 6.0 with Windows Vista.
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Tue Feb 22, 2011 7:06 am    Post subject: Reply with quote

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).


Quote:
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.


Quote:
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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Feb 22, 2011 10:11 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Tue Feb 22, 2011 10:34 am    Post subject: Different Salflibc versions, different runtime behaviour Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Tue Feb 22, 2011 11:32 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Feb 23, 2011 10:08 am    Post subject: Reply with quote

I will pass on your recommendation to the person responsible for this code.
Back to top
View user's profile Send private message AIM Address
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Thu Feb 24, 2011 7:32 pm    Post subject: Reply with quote

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.

Edit : 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 Smile
David.
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Thu Mar 03, 2011 8:14 pm    Post subject: Reply with quote

Quote:
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.


Quote:
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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Mar 04, 2011 10:18 am    Post subject: Reply with quote

Just to clarify, this is an issue (a potential bug) that is being investigated and hopefully will shorty be resolved.
Back to top
View user's profile Send private message AIM Address
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Fri Apr 08, 2011 11:15 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
Martin



Joined: 09 Sep 2004
Posts: 43

PostPosted: Tue Apr 12, 2011 6:27 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group