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 

Format bug
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Oct 08, 2015 9:17 pm    Post subject: Format bug Reply with quote

A bug? Should go to 999, isn't it ?

Code:
i=10
write(*,'(i1)',err=999) i

Print*, 'Goes here if this is compiler bug'
Stop

999 Print*, 'Goes here if there is no compiler bug'

end
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Thu Oct 08, 2015 11:58 pm    Post subject: Reply with quote

No bug here, not in the compiler.

If you had checked the output produced by the WRITE, you would have received a clue to what happened, which is specified by the Fortran standard as follows On output, if an exponent exceeds its specifi ed or implied width using the E, EN, ES, D, or G edit descriptor, or the number of characters produced exceeds the fi eld width, the processor shall fill the entire fi eld of width w with asterisks.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Oct 09, 2015 1:18 am    Post subject: Reply with quote

Let it fill the whole field with the asterisks or other garbage but what we see in the output shows some kind of conflict and for sure has to have the means for programmer to be managed. So i instructed compiler that in case of problem redirect the output to 999. it did not react. If Standard things that this is normal the Standard must be changed because this is obviously not. Though i'd be happy if Silverfrost just made an extension

And what means "If you had checked the output produced by the WRITE" ? ROTFL. Having bad day again?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Oct 09, 2015 3:11 am    Post subject: Reply with quote

Dan,

What is included as a reported error condition has always been debated.
Numeric overflow for the available field is explicitly discussed in the standard and a non-error condition response is provided.

If you want a different response, then you need to code for it, using out of range testing.

There are lots of problems with what is or is not an error condition, where an err= or iostat= response should be expected. (are they listed in the standard ?)

When using F77, I had coded an internal "read (string,fmt='(i10)',iostat=ii) num" to test if string contained a valid integer. This all worked well with many compilers until I transferred the code to an IBM compiler and the program crashed with an undetected error. I found that what was an expected error detection condition was up to the compiler developer. One of the many failings of the F77 standard, which I blamed on IBM.

I am also worried by the problem when using FTN95 business format, using B'ZZZ,ZZZ,ZZ#' instead of B'---,---,--#' if reporting -ve values. Should using B'ZZZ,ZZZ,ZZ#' be an error ?

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



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Oct 09, 2015 6:22 am    Post subject: Reply with quote

Nothing to debate here, John. The code
Code:
i=10
write(*,'(i1)') i

should produce on output what it produces right now, the asterisks, the stars or whatever. While if err=999 is explicitly used
Code:
i=10
write(*,'(i1)',err=999) i


the code should be directing its execution where programmer wants it to. Why the heck i wrote err=999? To be ignored? That is the dumbest absurd of Standard committee.

I just lost two days with such error produced by C. And my colleagues spent a month before having no idea what sometimes happening with the code. The huge files ~10 GB can be contaminated with few NAN numbers somewhere in the middle so that it was impossible even to look inside, and even if you look you will not spot them. Following the design ideology of this compiler with its strictest checking of everything it should not follow BS other compilers do and if user is concerned do not allow the behavior like we discuss above.

This compiler made so many extensions to the Fortran Standard that adding one million more will not even be noticed Smile
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Oct 09, 2015 8:14 am    Post subject: Reply with quote

I think that jumping to the alternate return could be useful and probably fairly easy to implement. At the same time it could be unwelcome in some user's existing code.

The relevant FTN95 library code is in the DLL - i.e. a runtime issue, so it would be tricky to provide an FTN95 command line switch for this feature. However, we might be able to use an environment variable for this purpose. Another way would be provide a subroutine call to switch this feature on.

Any thoughts?
Back to top
View user's profile Send private message AIM Address
IanLambley



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Fri Oct 09, 2015 12:23 pm    Post subject: Reply with quote

Dan,
The action of the print statement whereby asterisks are printed for an overflow is the saviour of every Fortran programmer and just a sign that their format need widening. It is not an error. Please Paul, do not change it!

A simple work-around.
Code:

      character*1 result

      i=10
      write(result,'(i1)') i
      if(result .eq. '*')then
        Print*, 'Goes here if there is an overflow'
      else
        Print*, 'Goes here if there is not an overflow'
      endif
      Print *,result
      end


or

Code:

      i=10
      if(abs(I>9)then
        Print*, 'Goes here if there is an overflow'
      else
        Print*, 'Goes here if there is not an overflow'
      endif
      Print '(i1)',i
      end




Ian
Back to top
View user's profile Send private message Send e-mail
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Oct 09, 2015 3:18 pm    Post subject: Reply with quote

My suggestion does not break any valid code, Paul and Ian. There could be done few workarounds of course. My suggestion is very logical and very simple: if user wrote err=label then in case of error it must be granted not ignored.

/* Some though like the Ian's first one could make loading or writing of my 10 of 10GB files painfully longer. Welcome to the 64 bit world where i/o speed and error checking needs better quality.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Oct 09, 2015 5:03 pm    Post subject: Re: Reply with quote

DanRRight wrote:
My suggestion does not break any valid code, Paul and Ian.

Not true. If a WRITE were done to a field that was not sufficiently wide, and such a WRITE should activate an ERR= clause if that clause is present, as you want, the program would need to be terminated when no ERR= or IOSTAT= clause is present, because 9.11.2-2 of the Fortran 2008 standard says If an error condition occurs during execution of an input/output statement that contains neither an ERR= nor IOSTAT= specifier, error termination of the program is initiated. IanLambley's first program, for instance, would have to be terminated at the WRITE statement.

For your suggestion to work without breaking valid code, the WRITE would have to cause an error state to be entered only when an ERR= clause is present. In other words, it should be an error only if you check for an error (with the ERR=clause).

Paul, even if it appears simple to change SALFLIBC.DLL to make writing to an insufficient field width an error, it would require much care and effort to shield users from such nonstandard behavior. Consider a specific example: I write code that uses DanRRight's library code. I expect standard behavior, the DRR library code requires non-standard behavior, and both segments of code may do formatted I/O. Will SALFLIBC.DLL support both behaviors simultaneously? This is an instance where setting an environmental variable would not work. If you required a dedicated subroutine call to initiate the nonstandard behavior, on the other hand, different problems arise. Will I then have to make a second dedicated subroutine call in my code to restore standard behavior, after control returns to my code following a call to the DRR library?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Oct 09, 2015 6:25 pm    Post subject: Reply with quote

Perhaps I have not stated my suggestion clearly.

I am offering to provide a user callable FTN95 library routine such that, only when it is called, you will get the behaviour that Dan is asking for. So nothing changes unless and until this new routine is called somewhere before the related print statements.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Oct 09, 2015 8:31 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:
Perhaps I have not stated my suggestion clearly.

I am offering to provide a user callable FTN95 library routine such that, only when it is called, you will get the behaviour that Dan is asking for. So nothing changes unless and until this new routine is called somewhere before the related print statements.

I understand that, but my concern is as follows: once the to-be-provided subroutine in SALFLIBC is called, the behavior gets changed irrevocably.

It should be possible to revert to present behavior as desired; in other words, that subroutine call should be a toggle.

There is another thorny issue that will have to be dealt with. If you accept an ERR= clause, you will probably also have to accept an IOSTAT= clause, and decide upon a set of IOSTAT values to identify different types of errors (some of which are not errors according to the Fortran standard). Without a full set of IOSTAT values, merely reaching the target statement number of ERR= will probably not enable recovery from the error.

For instance, in Dan's example, WRITE(*,'(I1)',ERR=100)I, what would happen with I=-1? What if the format string and the I/O list contained mismatches? For example, WRITE(*,'(I1)', ERR=100)STR, where STR is a character variable?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Oct 10, 2015 8:09 am    Post subject: Reply with quote

Yes, naturally the subroutine would provide a toggle. After that users can use the routine or not depending on how useful they find it.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Oct 11, 2015 1:49 am    Post subject: Reply with quote

Paul,

That should solve Dan's problem; a bit like handling tab characters for formatted reads ( see READ_TABS@ with OPEN )

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



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Sun Oct 11, 2015 8:19 am    Post subject: Reply with quote

Paul,
Will this need to be turned on and off because in some few cases the above response may be required. In other cases the normal response may be required. Perhaps there should be an option to automatically turn off the feature after it has responded as Dan requires. Switch it on only before the statement where it is needed and automatically turn off after the statement has executed.
Ian.
Back to top
View user's profile Send private message Send e-mail
PaulLaidler
Site Admin


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

PostPosted: Sun Oct 11, 2015 8:34 am    Post subject: Reply with quote

OK. I am thinking that we could have a general routine to configure the I/O with a flag for each option. One option would be equivalent to READ_TABS@ etc.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
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