>> write (*,'(a)',advance='no') "x = "
>> read *, x

doesn't work: no text appears on the screen before enter/return is pressed.

>> write (*,'(a)',advance='no') "x = "
>> close (6)
>> read *, x

works correctly, but then there will be no more output on the screen (print *, ... ; write (*,*) ...) for the rest of the program.

any idea? thanks!

p.s.: i use "Fortran Compiler for 32-bit applications, Version 7.0 Build 20030129Z" on linux redhat 8.0

22 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Try a current 7.1 compiler. The behavior you're seeing is standard-conforming, but not very popular. I think this was changed for 7.1.


Retired 12/31/2016

yes it works quite well! (both with and without 'close')

another problem exists in connection with the T-format:

>> write (*,'(t30,a,t20,a,t10,a)') "30", "20", "10"


>> _________10________20________30


>> write (*,'(t30,a,)',advance='no') "30"
>> write (*,'(t20,a,)',advance='no') "20"
>> write (*,'(t10,a,)')_____________ "10"

results in

>> _____________________________30___________________20 __________10

so the position counting starts after the end of the last writing (though "advance='no'"). even with the TL format one cannot go before this point.

any idea?

(p.s.: i use "_" instead of blanks, because more blanks will only be shown as one.)

I had to stare at the standard for a while to make sure I understood what should happen. I agree with you that ifc 7.1 gets it wrong. The next major release, due towards the end of this year, will get it right (the I/O libraries come from CVF and they do it right.)


Retired 12/31/2016

all right, i'll wait for that.

thank you!

Steve said he agreed that ifc 7.1 is getting this wrong. When I read the standard, it appears to me that ifc 7.1 is getting it right. The standard says:

The Tn edit descriptor indicates that the transmission of the next character to or from a record is to occur at the nth character position of the record, relative to the left tab limit.

This appears to me to be what ifc is doing. The first nonadvancing write tabs to column 30 and puts out "30". At the beginning of the next write, the left tab limit is set to the current position in the record (i.e., column 32) and it tabs to the 20th column relative to that (i.e., column 51 in absolute terms) and put out "20". Similarly, the third write sets the left tab limit to the current posiont (now column 53), tabs to column 10 relative to that (in absolute terms, column 62), puts out "10" and ends the records. This appears to be what ifc is doing. What do you think should be the output of these statements?

maybe the behaviour is standard-conform, i don't know.

i would like to get the same output as in the first example, say as long as the record (if this is the right meaning of record) is not closed ("advance='no'" should keep it open) i would like to be able to reach every position within this record (line), that means also to be able to go to a position before the last written one.

maybe the standard does not allow that, but i would like to have such a possibility, especially for a running counter, e.g.:

do i=1,n
__... ! do something w/o printing/writing on the screen
__write (*,'(t1,i6)',advance='no') i
end do

Interesting. I had apparently entirely missed the part about "left tab limit". It could indeed be that ifc has the correct behavior here - we'll investigate.


Retired 12/31/2016

Upon further investigation, my initial response was incorrect. This is a bug and I have reported it to engineering.


Retired 12/31/2016

after so many responses:

1. what was your "initial response"?
2. what is the bug now? ("this is a bug")

My initial response was that CVF was correct and ifc was wrong. My reconsidered response was that CVF was wrong and ifc was correct. Unfortunately, there's a real possibility that the next Intel Fortran for Linux will pick up the bad CVF behavior unless the bug gets fixed in time for the release. I have submitted it to the engineers as a bug report.


Retired 12/31/2016

so it is the bad/uncorrect behaviour that i would like to have (running counter, reaching any position within the topical line)?
wouldn't this be a more flexibel behaviour?

I have the same problem with advance="no". I have loaded the currently available version. Advance="no" does not appear to flush the output buffer to produce any screen output. Short of an close/open sequence, can you think of any other workaround?

Sandwich - while it may seem more flexible, it's not what the standard says and can cause problems with implementations that want to flush the partial line. It assumes that you can reliably reposition in a partial record that was already written.

Finneyb, you may have an old version of Intel Fortran - try getting the latest update.


Retired 12/31/2016

No, as I stated, I have the most current version available.

Well, I THOUGHT I had the most recent version (I had 7.1.008). 7.1.030 did the trick. Thanks Steve.

well, steve, the standard is the chief, isn't it?

p.s.: how can a simple user make suggestions to the standard makers?

You could contact a committee member and make your suggestion, but if you want to suggest changing this behavior, it will never fly, as it would break existing, standard-conforming code.


Retired 12/31/2016

as i have some other ideas, could you please give me some e-mail adresses of committee members?

Sorry, that's not for me to do.

Let me suggest that the comp.lang.fortran newsgroup is a good place to start a discussion of such things. Several members of the committee follow it and may respond.


Retired 12/31/2016

o.k. thanx.


Leave a Comment

Please sign in to add a comment. Not a member? Join today