Why it is forbidden?
in [Fortran]
|
Prev: Caveat: Can One Dim Local Arrays Using Argument List Integers ??
Next: Spam removal - volunteer?
From: Den7 on 21 Dec 2009 10:27 Thanks to all for discussions. I plan to request from my Fortran 95 compiler developers to address this issue at least as an extension, so what specifically i have to ask as program-minimum and program- maximum? My minimum requirement is at least to make the code not crash, this is totally disgusting and DOS-ish. To make my request completely focused and more solid please check these two snippets work. The fact it works in some other compilers usually stimulates developers most. Actually where i use it is a bit more complex and not exactly what you see here, and is related to Windows GUI builder where utilizing Windows mouse realtime handling may cause out-of-normal-order flow of the fortran code in callback functions and its crash due to multiple internal writes could be not completed and overlap in time. Result is a crash. Yuck. So because I have to ask exactly what i need, the program-maximum is (can i mask more?) integer foo external foo open(11,file='11.out') open(11,file='12.out') write(11,*) foo(12) end integer function foo(i) character*9 char_I write(char_i,'(i9)') i write(12,*,err=1000) char_i 1000 foo=i end Or at least the code does not crash on internal write or internal read (the program-minimum) integer foo external foo open(11,file='11.out') write(11,*) foo(12) end integer function foo(i) character*9 char_I write(char_i,'(i9)',err=1000) i 1000 foo=i end Or may be ask for implementing ENCODE/DECODE not via internal write? Almost all compilers support it based on Polyhedron review.
From: Den7 on 21 Dec 2009 10:36 Thanks to all for discussions. I plan to request from my Fortran 95 compiler developers to address this issue at least as an extension, so what specifically i have to ask as program-minimum and program- maximum? My minimum requirement is at least to make the code not crash, this is totally disgusting and DOS-ish. Yuck. To make my request completely focused and more solid please check these two snippets work. The fact it works in some other compilers usually stimulates developers most. Actually where i use it is a bit more complex and not exactly what you see here, and is related to Windows GUI builder where utilizing Windows mouse realtime handling may cause out-of-normal-order flow of the fortran code in callback functions and its crash due to multiple internal writes could be not completed and overlap in time. So because I have to ask exactly what i need to make the request done quick, the program-maximum is integer foo external foo open(11,file='11.out') open(11,file='12.out') write(11,*) foo(12) end integer function foo(i) character*9 char_I write(char_i,'(i9)') i write(12,*,err=1000) char_i 1000 foo=i end Or at least the code does not crash on internal write or internal read (the program-minimum) integer foo external foo open(11,file='11.out') write(11,*) foo(12) end integer function foo(i) character*9 char_I write(char_i,'(i9)',err=1000) i 1000 foo=i end Or may be ask for implementing ENCODE/DECODE not via internal write? Almost all compilers support it based on Polyhedron review. Can i ask something else?
From: Den7 on 21 Dec 2009 11:07 Thanks all for valuable discussion. I plan to request from my Fortran 95 compiler developers to address this issue at least as an extension, so what specifically i have to ask as program-minimum and program- maximum? My minimum requirement is at least to make the code not crash, this is totally disgusting and DOS-ish. Yuck. To make my request completely focused and more solid please check if these two snippets work. The fact it works in some other compilers usually stimulates developers most. Actually where i use it is a bit more complex and not exactly what you see here, and is related to Windows GUI builder where utilizing Windows mouse realtime handling may cause out-of-normal-order flow of the fortran code in callback functions and its crash due to multiple internal writes could be not completed and overlap in time. So because I have to ask exactly what i need to make the request done quick, my program-maximum is integer foo external foo open(11,file='11.out') open(12,file='12.out') write(11,*) foo(12) end integer function foo(i) character*9 char_I write(char_i,'(i9)') i write(12,*,err=1000) char_i 1000 foo=i end Or at least the code does not crash on internal write or internal read (the program-minimum): integer foo external foo open(11,file='11.out') write(11,*) foo(12) end integer function foo(i) character*9 char_I write(char_i,'(i9)',err=1000) i 1000 foo=i end Or may be ask for implementing ENCODE/DECODE not via internal write? Almost all compilers support it based on Polyhedron review. Can i ask something else?
From: Tim Prince on 21 Dec 2009 12:54 Den7 wrote: > > So because I have to ask exactly what i need, the program-maximum is > (can i mask more?) > > integer foo > external foo > > open(11,file='11.out') > open(11,file='12.out') > write(11,*) foo(12) > end > > integer function foo(i) > character*9 char_I > write(char_i,'(i9)') i > write(12,*,err=1000) char_i > 1000 foo=i > end > > > Or at least the code does not crash on internal write or internal read > (the program-minimum) > > integer foo > external foo > > open(11,file='11.out') > write(11,*) foo(12) > end > > integer function foo(i) > character*9 char_I > write(char_i,'(i9)',err=1000) i > 1000 foo=i > end > > Or may be ask for implementing ENCODE/DECODE not via internal write? > Almost all compilers support it based on Polyhedron review. Your minimum version appears to be covered under f2003. It seems unlikely that adding a 35-year backward looking extension would be as promising as selected f2003 support. You got the answers about how your maximum version was difficult to implement and is not standard compliant.
From: Den7 on 21 Dec 2009 13:50
On Dec 21, 2:55 am, robert.corb...(a)sun.com wrote: > On Dec 20, 8:56 pm, Den7 <rrr7...(a)gmail.com> wrote: > > > > > > > Please look at this code, why this code is forbidden (in my compiler > > at least) ? > > > integer foo > > external foo > > > open(11,file='11.out') > > open(12,file='12.out') > > write(11,*) foo(12) > > end > > > integer function foo(i) > > write(12,*) i > > 1000 foo=i > > end function foo > > > Even if i write into character variable (so called internal write or > > something like that) i have the same problem. > > Even more, if i make > > > write(12,*,err=1000) i > > > i still have the crash. How about your compiler? > > > The error is "The function called from within an I/O statement has > > itself performed an I/O". > > It sounds to me as silly as this: "The function called from within > > multiplication has itself performed a multiplication", but there could > > be nasty reasons for forbidding this kind of I/Os requiring > > multithreading or so. > > > How old VAX ENCODE is implemented in your compiler? Is it done via > > internal write or by some proprietary other non-I/O way? In other > > words, can you check if this code below is also crashing, and if it > > does, is it crashing on ENCODE line statement or on the next lines > > with WRITE statement? Or may be your compiler allows all these writes > > and you do not experience a problem at all despite the standard may > > forbid that? (Please also check syntax of this snippet, i can not run > > it, my compiler does not support these long forbidden ENCODE/DECODE > > extensions) > > > open(11,file='11.out') > > open(12,file='12.out') > > write(11,*) foo(1) > > end > > > integer function foo(i) > > character*9 CHAR_I > > > ENCODE (9,1,CHAR_I) i > > 1 format (i9) > > write(12,*) char_i > > > write(12,*) i > > > foo=i > > end > > > TIA ! > > Sun Fortran has allowed "recursive" I/O involving > different I/O units since the 2.0 release of Sun f90. > It was hard to implement, but it was well worth the > effort. > > Allowing recursive I/O to the same unit is an often > requested extension, but it is problematic. What > should happen if a program closes a file in the middle > of writing to that file? One case that could be allowed > and that seems to be what most people who ask for the > extension want is to allow a formatted WRITE on a unit > which is already being used in another formatted WRITE. > > Bob Corbett Aren't my examples which write NOT IN THE SAME UNIT but into two different I/O using have to be allowed? |