User Defined Derived-Type IO in gfortran

[paul.rich...@gmail.com]

Dear All,

Jerry DeLisle and I committed the first implementation of UD-DTIO for gfortran 7.0.0 on 31st August.

At present, UD-DTIO will not work with internal units. We hope that this will follow soon.

We would be grateful for as much testing as possible and that bugs be reported on gcc Bugzilla.

Best regards

Paul

[Stefano Zaghi]

Dear Paul, you are my hero! Thank you very very very much! Your work is very appreciated, I hope to test it soon.

P.S. is there any chance to know the roadmap toward Parametrized Derived Type implementation?

My best regards.

[paul.rich...@gmail.com]

From all I have heard, PDTs are the K2 of fortran compiler development. Certainly, the scoping work that I have done indicates that this is so. At present, the order of priority for my work is:
(i) Fix the problems with pointer arrays, where they point to components of arrays of derived-types (The last incompletely implemented F95 feature);
(ii) Fix the problem of clashes of derived-type names in OOP (flagged up on this list);
(iii) Recursive allocatable components of derived-types, for which a patch already exists and has to be brought out of storage; and then
(iv) Parameterized Derived-Types.

The first three will make it to 7.0.0. Whether or not PDTs make it, depends crucially on a light-bulb moment as to how to implement economically. Also, I have to play my part in general bug fixing so there simply might not be time for PDTs.

Best regards

Paul

[Stefano Zaghi]

Dear Paul,

With just the first 3 items my next Christmas' tree will be full of great presents... you are my superhero! Thank you again so much!

My best regards.

[Gary Scott]

:) I was hoping for a new Tesla, but I'll take it.

[Neil]

On Monday, September 5, 2016 at 1:32:29 PM UTC-6, paul.rich...@gmail.com wrote:
> From all I have heard, PDTs are the K2 of fortran compiler development.

I wonder how finalization (PR37336) and deferred length characters (PR68241) stack up in difficulty. I'd love to see those finished.

[paul.rich...@gmail.com]

Dear Neil,

These are on the menu. However, the current stage of the gcc release cycle is the opportunity to introduce new features.

Regards

Paul

[Stefano Zaghi]

Dear Paul,

I am sorry to bother you here, I know that I could find my answers on GNU gcc docs. Can you point me to the right place to download the branch you are working on? I would like to test it, at least for giving you some feedback, but I am not sure where to find your 7.x branch.

I am a git addicted man, so I am searching on the git mirror. I found one of your last commit (11 min ago) here:

https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/fortran-dev

I guessed that this is the commit to be tested, does this right?

Can I clone just this branch and build as other gcc trunk, or I have to download the whole gcc branch?

In short, can you kindly give me the link to download the sources you like we test?

Thank you very much again!

My best regards.

[paul.rich...@gmail.com]

Hi Stefano,

The fortran-dev branch is dedicated to array descriptor reform. See https://gcc.gnu.org/wiki/ArrayDescriptorUpdate

It has lain dormant for a couple of years but has been revived and merged with version 7.0.0. There are still some bugs but they are being cleared very rapidly.

Features that aren't available in the current descriptor:

Stride in bytes rather than sizeof(array_element_type). This is needed in order to efficiently support derived type components.

Flags for allocated and associated status. This avoids ugly workarounds like allocating a 1 byte array for zero sized allocations, see e.g. PR 35719, and is probably necessary for solving PR 35718.

Store each dimension as a (lbound, stride, extent) triplet rather than the current (lbound, stride, ubound). With the former ubound can be calculated as ubound = lbound + stride * extent which is essentially free whereas with the current setup extent must be calculated as extent = (ubound - lbound) / stride where the division is quite expensive. See e.g. tables with instruction timings and throughput.

* Support rank 15 arrays

* Save coarray information

* Save type information for (a) polymorphic data types but also (b) for run-time diagnostic.

* Support TR 29113 "Further Interoperability of Fortran with C", preferably as native format.

Yes, you have to download the branch.

Ciao

Paul

[jvdel...@gmail.com]

On 23rd of September, the internal units portion of the UD-DTIO was committed to gfortran trunk, aka Version 7.

The gcc git mirror is here: https://gcc.gnu.org/wiki/GitMirror for those who may want to git it.

Otherwise got here: https://gcc.gnu.org/ and look on the roght side for SVN Read accessn and above that instructions to build it under https://gcc.gnu.org/install/

Testing and bug reports much appreciated.

Jerry

[vladim...@gmail.com]

> It has lain dormant for a couple of years but has been revived and merged with version 7.0.0. There are still some bugs but they are being cleared very rapidly.

Wow it looks like version 7 will be a big leap forward! Great job.

[FortranFan]

On Thursday, September 29, 2016 at 9:33:45 PM UTC-4, Jerry Delisle wrote:

> ..

>
> Testing and bug reports much appreciated.
>
> Jerry

To the wonderful gfortran developers:

I apologize for not using bugzilla and the mailing list - have some practical and personal constraints.

On UDDTIO and generic bindings, I've a question: my understanding per the Fortran standard is the generic binding has to be PUBLIC in order for it to be 'consumed', however the example below shows gfortran works just fine without that being the case - do you think it is correct?

-- begin code --
module string_m

implicit none

private

type, public :: string_t
private
character(len=:), allocatable :: m_s
contains
private
procedure, pass(this) :: assign_s
procedure, pass(this) :: write_s
generic, public :: assignment(=) => assign_s
generic :: write(formatted) => write_s ! PUBLIC attribute missing
end type string_t

contains

subroutine assign_s( this, rhs )

class(string_t), intent(inout) :: this
character(len=*), intent(in) :: rhs

this%m_s = rhs

return

end subroutine assign_s

subroutine write_s(this, lun, iotype, vlist, istat, imsg)

! argument definitions
class(string_t), intent(in) :: this
integer, intent(in) :: lun
character(len=*), intent(in) :: iotype
integer, intent(in) :: vlist(:)
integer, intent(out) :: istat
character(len=*), intent(inout) :: imsg

! local variable
character(len=9) :: sfmt

sfmt = "(A)"
if ( (iotype == "DT").and.(size(vlist) >= 1) ) then

! vlist(1) to be used as the field width of the character component.
write(sfmt,"(A,I2,A)", iostat=istat, iomsg=imsg ) "(A", vlist(1), ")"
if (istat /= 0) return

end if

write(lun, fmt=sfmt, iostat=istat, iomsg=imsg) this%m_s

return

end subroutine write_s

end module string_m
program p

use string_m, only : string_t

type(string_t) :: s

s = "Hello World!"

print *, "s says ", s ! How can the processor handle this list-directed
! output unless string_m has PUBLIC generic
! binding for write(formatted) procedure bound
! to string_t derived type?

stop

end program p
-- end code --

[FortranFan]

On Monday, October 3, 2016 at 5:13:04 PM UTC-4, FortranFan wrote:

> On Thursday, September 29, 2016 at 9:33:45 PM UTC-4, Jerry Delisle wrote:
>
> > ..
> >
> > Testing and bug reports much appreciated.
> >
> > Jerry
>
> To the wonderful gfortran developers:
>
> I apologize for not using bugzilla and the mailing list - have some practical and personal constraints.
>

> On UDDTIO ..


Also, please note 9.43 in the Fortran 2008 standard document that says, "When an internal unit is used with the INQUIRE statement, an error condition will occur, and any variable specified in an IOSTAT= specifier will be assigned the value IOSTAT_INQUIRE_INTERNAL_UNIT from the intrinsic module ISO_FORTRAN_ENV (13.8.2)."

The gfortran development version I tried does not seem to issue the above error condition with an INQUIRE on an internal file IO whereas Intel Fortran does do so. You may want to investigate.

[steve kargl]

FortranFan wrote:

> On Monday, October 3, 2016 at 5:13:04 PM UTC-4, FortranFan wrote:
>
>> On Thursday, September 29, 2016 at 9:33:45 PM UTC-4, Jerry Delisle wrote:
>>
>> > ..
>> >
>> > Testing and bug reports much appreciated.
>> >
>> > Jerry
>>
>> To the wonderful gfortran developers:
>>
>> I apologize for not using bugzilla and the mailing list - have some practical and personal constraints.
>>
>> On UDDTIO ..
>
>
> Also, please note 9.43 in the Fortran 2008 standard document that says,
> "When an internal unit is used with the INQUIRE statement, an error condition

> will occur, and any variable specified in an IOSTAT= specifier will be assigned

> the value IOSTAT_INQUIRE_INTERNAL_UNIT from the intrinsic module
> ISO_FORTRAN_ENV (13.8.2)."
>
> The gfortran development version I tried does not seem to issue the above
> error condition with an INQUIRE on an internal file IO whereas Intel Fortran
> does do so. You may want to investigate.

Example code? It is difficult to fix bugs that are not reported via official
channels. It is especially difficult when the unreported bug has no
example code, which then relies on the expectation that someone might
stumble onto a random USENET post and be inclined to write said code.

--
steve

[FortranFan]

On Tuesday, October 4, 2016 at 2:54:49 PM UTC-4, steve kargl wrote:

> ..

>
> Example code? It is difficult to fix bugs that are not reported via

> channels. ..


@steve kargl,

I would have expected you to have realized that in this case, it's NOT a bug that I am pointing out to gfortran developers, rather it is a note from the Fortran standard. I'm lousy at standard-speak and my own understanding of the underlying comp. sci. principles and programming language semantics and the data and organization foundation of Fortran is worse: at times, I find figuring out the standard is as difficult as interpreting a nation's constitution, with me almost always getting it wrong.

For the situation at hand, I do not know if my own reading is correct, or that the other compiler is right.

So I was hesitant to go into further details beyond pointing out the relevant text from the standard; I would guess gfortran developers working on UDDTIO would be quite familiar with the context of the presented note, for after all the very task they embarked on was to implement a pending standard feature from over 12 years ago. So my hope is not to BIAS the developers in any way, let them do their own investigation if they are so inclined, and follow up as they find appropriate in full conformance with their own interpretation of the standard.

But now, should a gfortran developer insist on some code, here's one, a trivial extension of the earlier one I had provided. And anyone following up on it should keep the above comments in mind:

-- begin --

module string_m

implicit none

private

type, public :: string_t
private
character(len=:), allocatable :: m_s
contains
private

procedure, pass(this), private :: assign_s
procedure, pass(this), private :: write_s

generic, public :: assignment(=) => assign_s

generic, public :: write(formatted) => write_s
end type string_t

!.. Named constants
integer, parameter :: MAXLENS = 256

contains

subroutine assign_s( this, rhs )

class(string_t), intent(inout) :: this
character(len=*), intent(in) :: rhs

this%m_s = rhs

return

end subroutine assign_s

subroutine write_s(this, lun, iotype, vlist, istat, imsg)

! argument definitions
class(string_t), intent(in) :: this
integer, intent(in) :: lun
character(len=*), intent(in) :: iotype
integer, intent(in) :: vlist(:)
integer, intent(out) :: istat
character(len=*), intent(inout) :: imsg

! local variable

character(len=MAXLENS) :: sfmt
integer :: filesize

inquire( unit=lun, size=filesize, iostat=istat, iomsg=imsg )

if (istat /= 0) return

sfmt = "(A)"
if ( (iotype == "DT").and.(size(vlist) >= 1) ) then

! vlist(1) to be used as the field width of the character component.
write(sfmt,"(A,I2,A)", iostat=istat, iomsg=imsg ) "(A", vlist(1), ")"
if (istat /= 0) return

end if

write(lun, fmt=sfmt, iostat=istat, iomsg=imsg) this%m_s

return

end subroutine write_s

end module string_m
program p

use string_m, only : string_t

type(string_t) :: s

character(len=12) :: msg
integer :: istat
character(len=256) :: imsg

s = "Hello World!"

write( msg, "(DT)", iostat=istat, iomsg=imsg ) s
if (istat /= 0) then
print *, "write failed: istat = ", istat
print *, trim(imsg)
stop
end if

print *, "msg = ", msg

stop

end program p
-- end --

Upon execution with gfortran (GCC 7.0 development trunk),
msg = Hello World!


Whereas with Intel Fortran,
write failed: istat = 90
User Defined I/O procedure returned error 90, message: INQUIRE of internal unit-number is always an error (NOTE: unit identifies a file)

[steve kargl]

FortranFan wrote:

> On Tuesday, October 4, 2016 at 2:54:49 PM UTC-4, steve kargl wrote:
>
>> ..
>>
>> Example code? It is difficult to fix bugs that are not reported via
>> channels. ..
>
>

> I would have expected you to have realized that in this case, it's NOT a
> bug that I am pointing out to gfortran developers, rather it is a note from
> the Fortran standard. I'm lousy at standard-speak and my own understanding
> of the underlying comp. sci. principles and programming language semantics
> and the data and organization foundation of Fortran is worse: at times, I find
> figuring out the standard is as difficult as interpreting a nation's constitution,
> with me almost always getting it wrong.
>
> For the situation at hand, I do not know if my own reading is correct, or that
> the other compiler is right.
>
> So I was hesitant to go into further details beyond pointing out the relevant
> text from the standard; I would guess gfortran developers working on UDDTIO
> would be quite familiar with the context of the presented note,

Clearly, either gfortran or Intel has a bug.

So, instead of posting your 90 line example, you are hoping that someone
(possibly a gfortran developer) would simply whip together a 90 line code to
demonstrate what you think might be a bug in a compiler.

--
steve

[FortranFan]

On Tuesday, October 4, 2016 at 5:41:34 PM UTC-4, steve kargl wrote:

> ..
>

> Clearly, either gfortran or Intel has a bug.
>

An opinion which may be right or wrong!

> So, instead of posting your 90 line example, you are hoping that someone
> (possibly a gfortran developer) would simply whip together a 90 line code to
> demonstrate what you think might be a bug in a compiler.
>

> ..

@steve kargl,

Stop spouting nonsense: if you would read, you will know it is effectively a few lines (three even) of code that can be inserted into almost working example for UDDTIO in the gfortran test suite to demonstrate the difference between it and Intel Fortran, one line with an INQUIRE statement in UDIO procedure and a couple of lines in the caller to create an internal file IO. And YES indeed, one can very much hope anyone with the most rudimentary knowledge of UDDTIO will be able to put this together, for it's that trivial. Heck, if nothing else, someone can take an UDDTIO example from the Fortran standard itself (e.g., Note 9.48) and insert the few lines to check it out.

Just as with Al Gore and internet (! :-), I invented the very concept of 'minimal working examples' ok and apply it better than anyone else, so stop trying to https://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs

[steve kargl]

FortranFan wrote:

> On Tuesday, October 4, 2016 at 5:41:34 PM UTC-4, steve kargl wrote:
>
>> ..
>>
>> Clearly, either gfortran or Intel has a bug.
>>
>
> An opinion which may be right or wrong!

gfortran gives one result. intel gives different result. Both are supposedly
standard conforming compilers. Either one of these compiler must be wrong
or you have hit a processor-dependent behavior.

This statement from the standard

If file-unit-number identifies an internal unit (9.6.4.8.3),
an error condition occurs.

does not appear to yield too much processor-dependent behavior.

>> So, instead of posting your 90 line example, you are hoping that someone
>> (possibly a gfortran developer) would simply whip together a 90 line code to
>> demonstrate what you think might be a bug in a compiler.
>>
>

> Stop spouting nonsense.

It is not nonsense. You've identified a problem and you clearly had an example
code. Why not post it to save a developer time?

> And YES indeed, one can very much hope anyone with the most rudimentary
> knowledge of UDDTIO will be able to put this together, for it's that trivial. Heck,
> if nothing else, someone can take an UDDTIO example from the Fortran standard
>itself (e.g., Note 9.48) and insert the few lines to check it out.

A therein lies the problem. I did not write the UDDTIO support code for gfortran.
I do not use UDDTIO in my own code (for obvious reasons). I do, however, waste
my time fixing gfortran bugs (34 committed fixes this year with a few fixes still
sitting in my source tree). So, instead of helping someone that can investigate
an issue for you, you would rather play games. That's fine.

For the record, a 4 character patch to gfortran (that I just wrote while composing
this email) gives

% gfc7 -o z a.f90 -fdump-tree-original
% ./z
write failed: istat = 5018
Inquire statement identifies an internal file

with the code you posted upstream.
--
steve

[JerryD]

On 10/04/2016 01:25 PM, FortranFan wrote:
> On Tuesday, October 4, 2016 at 2:54:49 PM UTC-4, steve kargl wrote:
>
>> ..
>>
>> Example code? It is difficult to fix bugs that are not reported via
>> channels. ..
>

I need to make several points here:

1) Although I addressed the changes needed to give the error on inquire with a
parent statement, I did not address it for the case of an inquire inside a child
procedure. It must be handled just a little differently in the library code. So
I appreciate the example pointing it out. I have a patch already.

2) As one of the developers, although I read the standards often, I do not have
it memorized and there always seem to be use cases I don't think of. Examples
really do communicate. Example really, really help!

3) Because of (2), I rely on the user community to catch things I miss.

4) I only recently started to watch comp.lang.fortran and only because I knew
Paul posted this thread to get some attention on it. I posted likewise to keep
the user community informed. Otherwise I would probably not have seen this
INQUIRE issue.

5) It is really easy to post bugs on the gcc bugzilla web page and I do monitor
it multiple times per day. With that said, I would very much appreciate that
when people do see things, to post there. Here is a link to it:

https://gcc.gnu.org/bugzilla/

Kind Regards,

Jerry

[FortranFan]

On Tuesday, October 4, 2016 at 7:12:55 PM UTC-4, steve kargl wrote:

> ..
> On Tuesday, October 4, 2016 at 5:41:34 PM UTC-4, steve kargl wrote:
>
>> ..
>>
>> Clearly, either gfortran or Intel has a bug.
>

> This statement from the standard
>
> If file-unit-number identifies an internal unit (9.6.4.8.3),
> an error condition occurs.
>
> does not appear to yield too much processor-dependent behavior.
>

Well, if one is so certain about that, which part of the sentence from the standard brings in "either.. or.. " part to the earlier deduction?


>
> .. you clearly had an example code... So, instead of helping someone that can investigate

> an issue for you, you would rather play games. That's fine.

> ..

@steve kargl,

More than sufficient information was provided right upfront to a trivial oversight in the gfortran development version, related to a single sentence in a note in the Fortran standard, that anyone familiar with UDDTIO could have easily picked up and known what to do. And no, I didn't have any code that I was withholding, I'd only noticed some difference in internal file related IO when I was following up on some other matter, and I only put the example together in sheer bewilderment and utter disgust that someone would even bring it up without showing any situational awareness.

> For the record, a 4 character patch to gfortran (that I just wrote while composing
> this email)

> ..

Yep, that's all it should have taken to fix the issue, no big surprise there, but it should have taken far less time too. So stop with the robotic responses to save everyone's time.

[Thomas Koenig]

FortranFan <pare...@gmail.com> schrieb:

> More than sufficient information was provided right upfront to
> a trivial oversight in the gfortran development version,

[...]

I've had this same discussion recently on another newsgroup,
so I'll keep this short.

If you want a bug fixed, provide a test case, preferably in the gcc
bugzilla system. This is the established process, and developers,
whose time is quite limited, like it if people follow that process
because it saves time for them, time they would rather spend doing
other good things such as fixing bugs.

If you don't want a bug fixed .or. want to be ignored by the
developers (inclusive or), let the developers guess which what
the bug actually might be.

[herrman...@gmail.com]

On Wednesday, October 5, 2016 at 10:54:01 AM UTC-7, Thomas Koenig wrote:
> FortranFan <pare...@gmail.com> schrieb:

> > More than sufficient information was provided right upfront to
> > a trivial oversight in the gfortran development version,

(snip)

> If you want a bug fixed, provide a test case, preferably in the gcc
> bugzilla system. This is the established process, and developers,
> whose time is quite limited, like it if people follow that process
> because it saves time for them, time they would rather spend doing
> other good things such as fixing bugs.

As far as I know, gfortran isn't yet a Fortran 2008 compiler, so
not satisfying something in the Fortran 2008 standard isn't
yet a bug.

But otherwise, and as already noted, when asking for something
to be changed, it is nice to make it as easy as possible on those
you are asking. Supplying a program that demonstrates a bug,
or feature desired, makes it easier.

-- glen

[Richard Maine]

<herrman...@gmail.com> wrote:

> But otherwise, and as already noted, when asking for something
> to be changed, it is nice to make it as easy as possible on those
> you are asking. Supplying a program that demonstrates a bug,
> or feature desired, makes it easier.

I view this as just a special case of very general life advice far
beyond just software. When asking anyone for pretty much anything, do
what you can to make it as easy as reasonable for them. Doesn't really
matter whether it ought to be easy for them anyway; try to make it
easier.

Asking to borrow a whatever from a neighbor? Part of that question would
better be "When would it be convenient for me to come over and get it?"
rather than "Could you drop it off today?"

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[Gary Scott]

:) yes, but I have used products where there are 100s of anomalies.
I've spent countless hours debugging things for companies and providing
concise test cases. However, sometimes you can get frustrated when the
product is that buggy and you may decide you have a real job and can't
hold their hand for every case. I do sort of expect that companies
selling products actually have an in-house test process. Sometimes I
wonder if they just toss it over the wall for user's to debug.

[FortranFan]

> ..

>
> If you want a bug fixed, provide a test case, preferably in the gcc

> bugzilla system. This is the established process, ..

>
> If you don't want a bug fixed .or. want to be ignored by the
> developers (inclusive or), let the developers guess which what
> the bug actually might be.

@Thomas Koenig,

Look upthread and notice:

At 2:54:49 PM UTC-4 (Tuesday, October 4, 2016), steve kargl wrote: "Example code? .."

At 4:25:50 PM UTC-4 (Tuesday, October 4, 2016), I posted example code which is less than 2 hours after steve kargl post, but it was as soon as I noticed it.

That's that. Your comment about test cases is meaningless in this context.

Should you want to "waste more time" - yours and others - then look further upthread: a day earlier, at 5:13:04 PM UTC-4 (Monday, October 3, 2016) I had posted another query, INDEED with a test case. As a gfortran contributor, you know well there is no dearth of test cases waiting for fixes, including one I mention now that has been IGNORED thus far, while you and the other GCC guy are on and about making mountains out of mole hills. Focus on all the pending fixes, if you care. If you don't, I don't care for anything you have to say either, especially when I am most discerning on matters test cases, reproducers, MWEs and like, and fully aware of what is needed when.

[Richard Maine]

Gary Scott <garyl...@sbcglobal.net> wrote:

> On 10/5/2016 1:37 PM, Richard Maine wrote:
> > <herrman...@gmail.com> wrote:
> >
> >> But otherwise, and as already noted, when asking for something
> >> to be changed, it is nice to make it as easy as possible on those
> >> you are asking. Supplying a program that demonstrates a bug,
> >> or feature desired, makes it easier.
> >
> > I view this as just a special case of very general life advice far
> > beyond just software. When asking anyone for pretty much anything, do
> > what you can to make it as easy as reasonable for them. Doesn't really
> > matter whether it ought to be easy for them anyway; try to make it
> > easier.

...

> :) yes, but I have used products where there are 100s of anomalies.
> I've spent countless hours debugging things for companies and providing
> concise test cases. However, sometimes you can get frustrated when the
> product is that buggy and you may decide you have a real job and can't
> hold their hand for every case. I do sort of expect that companies
> selling products actually have an in-house test process. Sometimes I
> wonder if they just toss it over the wall for user's to debug.

Been there. Done that. Including with Fortran compilers and other
products. When I run into more bugs than it seems worth my time to write
up decent reports on, that generaly means I write off that one as having
been a bad purchase (even if the monetary price was $0, because I
invested at least my time in running into the bugs.)

[Thomas Koenig]

Dear FortranFan,

> As a gfortran contributor, you know well there is no
> dearth of test cases waiting for fixes, including one I mention
> now that has been IGNORED thus far, while you and the other GCC
> guy are on and about making mountains out of mole hills.

you now have the honor of being the first member of my
kill file for c.l.f.

Enjoy!

[FortranFan]

On Thursday, October 6, 2016 at 2:00:28 AM UTC-4, Thomas Koenig wrote:

> .. FortranFan,
> ..

>
> you now have the honor of being the first member of my
> kill file for c.l.f.
>
> Enjoy!

Dear Diary,

Some good news, the response was exactly as expected: as we have noted, the most ordinary of those in any position of self-assumed authority immediately go "off with his head" when they get called out on their own actions: http://www.phrases.org.uk/meanings/263700.html

[JerryD]

On 10/04/2016 06:13 PM, JerryD wrote:
> On 10/04/2016 01:25 PM, FortranFan wrote:
>> On Tuesday, October 4, 2016 at 2:54:49 PM UTC-4, steve kargl wrote:
>>
>>> ..
>>>
>>> Example code? It is difficult to fix bugs that are not reported via
>>> channels. ..
>>
>
> I need to make several points here:
>
> 1) Although I addressed the changes needed to give the error on inquire with a
> parent statement, I did not address it for the case of an inquire inside a child
> procedure. It must be handled just a little differently in the library code. So
> I appreciate the example pointing it out. I have a patch already.
>

Free as in Free Beer. The INQUIRE on internal unit inside a child DTIO procedure
is now fixed on gcc/gfortran trunk (aka version 7.0)

Cheers,

Jerry

[steve kargl]

You seem to have an interesting method of communication with those
in a position to improve a tool that you use. As you post from behind
a pseudonym, perhaps, English is a second language. Your posts in this
thread come across as flippant, antagonistic, and sometimes arrogant.
Neither Thomas nor I has any type of authority over you. Your above
response again demonstrates this impression.

You have now alienated two gfortran contributors. Perhaps, you have
achieved your purpose. For the record, Thomas' first ChangeLog entry
dates to 2007-03-04, and he has accumulated 238 entries since then.
My first ChangeLog entry occurred on 2003-06-24, and I now sit at 357
contributions. These numbers do not include the hundreds of code
reviews of others' patches. A simple "Thank You" would be appropriate
instead some copped attitude, but I doubt that that is forthcoming.

--
steve

[FortranFan]

On Thursday, October 6, 2016 at 12:56:33 PM UTC-4, steve kargl wrote:

> .. A simple "Thank You" would be appropriate

> instead some copped attitude, but I doubt that that is forthcoming.
>

> ..

@steve kargl,

See this link, my note dated Monday, September 12, 2016 at 3:41:16 PM UTC-4: https://groups.google.com/forum/#!searchin/comp.lang.fortran/FortranFan$20gfortran$20%22kudos%22%7Csort:relevance/comp.lang.fortran/D6-H5P9Hhe8/b3_fvrclBgAJ

And I can show posts going much farther back where I consistently show my appreciation, and that's when I am NOT a gfortran user. I never was and do not ever expect to be an actual user of gfortran for any endeavor of mine. For any actual programming needs, I've ALWAYS been paying and will continue to pay for a COMMERCIAL compiler.

> .. You seem to have an interesting method of communication with those
in a position to improve a tool that you use. ..

Silly impression!! I have no need for nor have any vested interest in gfortran besides the vague notion of some value it might bring to the general advancement of Fortran, totally predicated on the idea that newer Fortran standard features are being still implemented in the tool; should such work stop, I'll have no interest whatsoever.

Since I totally believe in the continuous improvement and advancement of technical computing in general, of Fortran in particular, and thereby the further extension of standard Fortran features, I dabble with compilers - if I can get access to versions - when newer facilities from the standard are implemented.

As humankind has learned, IDENTIFYING THE PROBLEM IS HALF THE SOLUTION. And that's my way of serving Fortran. So when I notice something, I say something with the hope it will benefit others, either as an alert online on something possibly not working right in some compiler version (people are so good now at online searches and information hardly ever disappears), or for interested developers to fix the issues, should they be so compelled either by commercial interests or some other (missionary) zeal. See here for another example: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/698477

Ask yourselves how many people are out there checking out the recently implemented UDDTIO feature in gfortran, especially when they themselves never expect to use it for their own work.

So those with any interest in GCC/gfortran take note: whether it is the cases involving UDDTIO in this thread that I have brought up, or those test cases I posted a while back with even Fortran 95 issues in gfortran, the bug fixes are not something I am asking for myself, not at all. They are totally intended to help all those who rely on the main open-source Fortran compiler for their computing.

> .. You have now alienated two gfortran contributors. ..

So I can't repeat often enough, I am NOT asking anyone to fix any gfortran issues for me - it makes no difference given my exclusive of commercial compilers for my own computing needs.

Most importantly, GCC volunteers should follow up on any posts of mine ONLY if the volunteers believe in Free Software Foundation (FSF), GNU/GCC/gfortran mission, FOSS, and all that, and if they know how to and are willing to read all the details, then if the content makes sense, and the posts are alerting to the possibility of some issues or bugs in gfortran that they care to address for their own sake and for the sake of the gfortran mission. That is, if the volunteer(s) are self-motivated and interested in the concept of gfortran being part of FSF that is free of such issues or bugs, etc. Otherwise, IGNORE my damn posts - you're more than welcome - whatever little I'm providing is free, open source type of information just like anything else from the FSF umbrella - take it or leave it, notice now the shoe is on the other foot.

> .. would be appropriate instead some copped attitude ..

I'm clear in my mind: it's you who consistently brings attitude and now the second gfortran contributor has joined in. The evidence is all there in this thread itself, you ask for a test case in a snarky manner and I immediately oblige with nary an angry word - see upthread - yet you pile on more remarks totally ignoring all my surrounding comments that in this particular instance I was specifically looking for a gfortran developer review of the standard for the sake of gfortran itself in terms of its UDDTIO implementation. It was to be followed by complete lack of situational awareness and further swipe by the other contributor. I'm not going to put up with it.

I only look to serve Fortran in my own little, convoluted manner, especially when I have NOTHING to gain personally NOR have any DESIRE for any acknowledgment for any testing and problem-reporting I might do with gfortran (and other compilers). Clearly such 'selfless' actions are something you and the other contributor cannot wrap your minds around, but it's not my problem, it's yours.

It's you who displays a lack of understanding of FSF and all that it entails and how to retain an inclusive tent which makes best use of the DIVERSE type of contributions, especially if one were to care for the idea of free, open source software which is also FREE of bugs and issues.

Stick with your antagonism and 'kill files' and all that, it's a most enlightened way to approach life.

It's only Fortran I care a little about.

[Stefano Zaghi]

Dear all,

I did not follow all the thread, just the few posts. Surely FortranFan does not need my defense neither (s)he asked for, but as (poor, mediocre) FOSS developer I appreciate a lot the great help that all his/her posts provide with many examples, snippets, pseudo codes...such a stuff is surely a contribution to FOSS movement. I am not up to the task to compare myself to GNU superheroes developers, but for me FortranFan has been proven to be a great resource. (S)he has a very concise "slang" (I think due to long experience), but (s)he is very kind for providing his/her help.

I say "thank you GNU gfortran developers" and also "thank you FortranFan".

My best regards.

[steve kargl]

FortranFan wrote:

> On Thursday, October 6, 2016 at 12:56:33 PM UTC-4, steve kargl wrote:
>
>> .. A simple "Thank You" would be appropriate
>> instead some copped attitude, but I doubt that that is forthcoming.
>>
>> ..

(deleted rant)

> Stick with your antagonism and 'kill files' and all that, it's a most enlightened way to approach life.
>
> It's only Fortran I care a little about.

@Message-ID: <6e5eab50-bf4a-4dc4...@googlegroups.com>
@Subject: Re: User Defined Derived-Type IO in gfortran
@From: FortranFan <pare...@gmail.com>
@ Injection-Date: Thu, 06 Oct 2016 13:41:19 +0000

> Dear Diary,
> Some good news, the response was exactly as expected:

et tu

--
steve

[michael siehl]

From my own experiences:
To a very large extend, gfortran/OpenCoarrays and ifort are (Fortran 2008) source code compatibel. This is especially true when it comes to coarrays (also because there are not too many coarray compilers available). Moreover, from my own coarray coding practice, these both compilers are complemantary when it comes to error messages from coarray coding mistakes: I found that the error messages from both compilers together (when used in conjunction on the same source code) gave the most complete picture of what was wrong with my code. Thus, I believe that ifort and gfortran do currently depend on each other, and that both are first class Fortran compilers. Personally, I find those compilers much more problematic that are lacking any support for coarrays.
Also, it's best practice to use (at least two) compilers in conjunction on the same source code wherever possible.

cheers

[FortranFan]

On Sunday, September 4, 2016 at 7:19:05 AM UTC-4, paul.rich...@gmail.com wrote:

> ..
>
> Jerry DeLisle and I committed the first implementation of UD-DTIO for gfortran ..

@Paul/Jerry DeLisle,

If you are still interested in gfortran implementation of defined input/output features, perhaps you can explain on this forum what is gfortran's intended facility for coders to perform list-directed input, specifically how the termination of the data transfer is to take place. Consider the following simple code:

--- begin code ---
module string_m

use, intrinsic :: iso_fortran_env, only : iostat_end, iostat_eor, output_unit

implicit none

private

type, public :: string_t
private
character(len=:), allocatable :: m_s
contains
private

procedure, pass(this) :: read_s
generic, public :: read(formatted) => read_s
end type string_t

contains

subroutine read_s(this, lun, iotype, vlist, istat, imsg)

! argument definitions
class(string_t), intent(inout) :: this

integer, intent(in) :: lun
character(len=*), intent(in) :: iotype
integer, intent(in) :: vlist(:)
integer, intent(out) :: istat
character(len=*), intent(inout) :: imsg

!.. Local variables
character(len=*), parameter :: sfmt = "(*(g0))"
character(len=1) :: c
integer :: i
integer :: rstat
character(len=256) :: rmsg

i = 0
istat = 0
imsg = ""
loop_read: do

i = i + 1
read( unit=lun, fmt="(a)", iostat=rstat, iomsg=rmsg ) c
select case ( rstat )
case ( 0 )
write( output_unit, fmt=sfmt) "i = ", i, ", iachar(c) = ", iachar(c)
case ( iostat_end )
write( output_unit, fmt=sfmt) "i = ", i, ", istat = iostat_end"
exit loop_read
case ( iostat_eor )
write( output_unit, fmt=sfmt) "i = ", i, ", istat = iostat_eor"
!istat = rstat !<--- X
exit loop_read
case default
write( output_unit, fmt=sfmt) "i = ", i, ", istat = ", rstat
istat = rstat
imsg = rmsg
exit loop_read
end select

end do loop_read

return

end subroutine read_s

end module string_m

program p

use string_m, only : string_t

type(string_t) :: s

read(*,*) s

end
--- end code ---

Upon execution, you will notice the gfortran output does not terminate the data transfer and the program is left hanging:

Hello
i = 1, iachar(c) = 72
i = 2, iachar(c) = 101
i = 3, iachar(c) = 108
i = 4, iachar(c) = 108
i = 5, iachar(c) = 111
i = 6, istat = iostat_eor

Notice the commented out line #52 above in the module string_m, the one marked "!<--- X". If this line is uncommented to return a nonzero value for the IOSTAT argument corresponding to IOSTAT_EOR intrinsic named constant, then the data transfer with the READ statement in the calling code is terminated. Is this what you think the standard intends with such list-directed input?

I personally believe gfortran implementation is incorrect here, but I'm more than eager to be proven wrong and hoping you or someone can explain what's going on in gfortran vis-a-vis the Fortran standard.

Thanks,

[Jerry Delisle]

On Sunday, December 17, 2017 at 1:52:04 PM UTC-8, FortranFan wrote:
--- snip ---

It is not hanging. The parent procedure is waiting to read the EOR which was consumed in the child READ loop. Since the procedure is not setting the iostat to cummunicate with the parent that it hit the EOR, the parent is simply waiting on input.

Jerry

[FortranFan]

On Tuesday, December 19, 2017 at 12:36:12 AM UTC-5, Jerry Delisle wrote:

> ..
> It is not hanging. The parent procedure is waiting to read the EOR which was consumed in the child READ loop. ..


@Jerry,

Thanks much for your response.

Re: your comment "Since the procedure is not setting the iostat to cummunicate with the parent that it hit the EOR, the parent is simply waiting on input." - have you discussed this with Paul et al. in conjunction with the Fortran standard, especially section 9.6.5 Termination of data transfer statements?

Section 9.6.5 has "Termination of an input/output data transfer statement occurs when .. list-directed data transfer exhausts the input-item-list .."

Do you not think an exhaustion of the input-item list has taken place with 'read(*,*) s' statement in the example code provided in the previous post, that the defined input for the derived type of s does NOT need to issue a nonzero IOSTAT to terminate the parent read?

[Jerry Delisle]

Your example program is invalid Fortran.

9.6.4.8 Defined input/output procedures
...
17 The iostat argument is used to report whether an error, end-of-record,
or end-of-file condition (9.11) occurs. If an error condition occurs, the
defined input/output procedure shall assign a positive value to the iostat
argument. Otherwise, if an end-of-file condition occurs, the defined
input procedure shall assign the value of the named constant IOSTAT_END
(13.10.2.16) to the iostat argument. Otherwise, if an end-of-record
condition occurs, the defined input procedure shall assign the value of
the named constant IOSTAT_EOR (13.10.2.17) to iostat. Otherwise, the
defined input/output procedure shall assign the value zero to the
iostat argument.

This requires that the user must set the iostat variable. The word "shall" and the requirements is explicit and on the user.

[FortranFan]

If any GCC volunteers are still interested in the defined input and output implementation in gfortran, here's another inquiry along with an example program.

The Fortran standard states in the section on defined input/output:
"If the iostat argument of the defined input/output procedure has a nonzero value when that procedure returns, and the processor therefore terminates execution of the program as described in .."

And separately in the section on Error conditions and the ERR= specifier, it states:
"If an error condition occurs during execution of an input/output statement that contains neither an ERR= nor IOSTAT= specifier, error termination is initiated"

Now consider this:

--- begin console output ---

xx>type p.f90
module m

use, intrinsic :: iso_fortran_env, only : iostat_eor

type :: t
integer :: i = 0
end type

interface read(formatted)
module procedure read_t
end interface

contains

subroutine read_t( dtv, lun, iotype, v_list, iostat, iomsg )

class(t), intent(inout) :: dtv

integer, intent(in) :: lun
character(len=*), intent(in) :: iotype

integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(len=*), intent(inout) :: iomsg

read( lun, fmt=*, iostat=iostat, iomsg=iomsg ) dtv%i

iostat = iostat_eor

return

end subroutine

end module

program p

use m

type(t) :: foo

read(*,*) foo

print *, "Hello World!"

stop 0

end program

xx>gfortran p.f90 -o p.exe

xx>p.exe
42
Hello World!
STOP 0

xx>ifort /standard-semantics /traceback p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 18.0.0.124 Build 20170811
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.11.25508.2
Copyright (C) Microsoft Corporation. All rights reserved.

-out:p.exe
-subsystem:console
-incremental:no
p.obj

xx>p.exe
42
forrtl: severe (157): Program Exception - access violation
Image PC Routine Line Source

p.exe 000000013F913EF8 Unknown Unknown Unknown
p.exe 000000013F8C66E8 Unknown Unknown Unknown
p.exe 000000013F8C3259 Unknown Unknown Unknown
p.exe 000000013F8D1C3B Unknown Unknown Unknown
p.exe 000000013F8B4E5E Unknown Unknown Unknown
p.exe 000000013F8B2D79 Unknown Unknown Unknown
p.exe 000000013F8B10D2 MAIN__ 40 p.f90
p.exe 000000013F9117F2 Unknown Unknown Unknown
p.exe 000000013F911B95 Unknown Unknown Unknown
kernel32.dll 00000000776659CD Unknown Unknown Unknown
ntdll.dll 000000007779A561 Unknown Unknown Unknown

xx>
--- end output ---

The questions:

1) Is the code standard-conforming?

2) If the answer to the first question is yes, then look at the run-time behavior shown above for the program output using gfortran and comment on whether it is consistent with the intended implementation of this facility in gfortran. That is, the nonzero IOSTAT argument returned by the defined input procedure does not lead to a process termination - is this only to be expected with gfortran? The above output also shows the run-time behavior with Intel Fortran where an exception is raised.

Thank you,

[steve kargl]

Code is invalid.

--
steve

[FortranFan]

On Wednesday, December 20, 2017 at 4:19:12 PM UTC-5, steve kargl wrote:

> FortranFan wrote:
>
> > module m
> >
> > use, intrinsic :: iso_fortran_env, only : iostat_eor
> >
> > type :: t
> > integer :: i = 0
> > end type
> >
> > interface read(formatted)
> > module procedure read_t
> > end interface

> ..
>
> Code is invalid. ..

Incorrect.

Anyways, for readers who are FOSS developers who may be looking to employ the implementation in the original post, caveat emptor: it fails to initiate error termination with nonzero IOSTAT argument when it should. That's the main point. The case presented being just a contrived attempt to show the problem. If one doesn't think some specific instruction is standard-conforming (which I wholly doubt), change it. Nonetheless my post upthread also showed how a commercial implementation handles it and from which there is to learn.

[FortranFan]

On Tuesday, December 19, 2017 at 12:36:12 AM UTC-5, Jerry Delisle wrote:

> ..

> It is not hanging .. simply waiting on input. ..

On Tuesday, December 19, 2017 at 9:33:56 PM UTC-5, Jerry Delisle wrote:
> ..
>

> Your example program is invalid Fortran.

Another instance of "invalid Fortran" (NOT!!!):

--- begin code ---
module m

type :: t
integer :: i = 0
end type

interface read(formatted)
module procedure read_t
end interface

contains

subroutine read_t( dtv, lun, iotype, v_list, iostat, iomsg )

class(t), intent(inout) :: dtv

integer, intent(in) :: lun
character(len=*), intent(in) :: iotype

integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(len=*), intent(inout) :: iomsg

select case ( iotype )

case ( "LISTDIRECTED" )

read( lun, fmt=*, iostat=iostat, iomsg=iomsg ) dtv%i

case ( "DT" )
! elided

case ( "NAMELIST" )
! elided

case default
! elided

end select

return

end subroutine

end module

program p

use m

type(t) :: foo

type(t) :: bar

read(*,*) foo, bar

print *, "foo%i = ", foo%i, ", bar%i = ", bar%i

stop 0

end program
--- end code ---

With Intel Fortran, the program execution completes as follows:
42,43
foo%i = 42 , bar%i = 43
0

With gfortran, "it's a bird, it's a plane, no it's superman" no.. it's a freeze, it's a hang, no wait, oh it's waiting, only waiting, really waiting, and "correctly" too - Intel Fortran be damned - forever and ever and ever:

xx>p.exe
42,43
At line 54 of file p.f90 (unit = 5, file = 'stdin')
Fortran runtime error: ^C

[kargl]

FortranFan wrote:

> On Wednesday, December 20, 2017 at 4:19:12 PM UTC-5, steve kargl wrote:
>
>> FortranFan wrote:
>>
>> > module m
>> >
>> > use, intrinsic :: iso_fortran_env, only : iostat_eor
>> >
>> > type :: t
>> > integer :: i = 0
>> > end type
>> >
>> > interface read(formatted)
>> > module procedure read_t
>> > end interface
>> ..
>>
>> Code is invalid. ..
>
> Incorrect.
>

The code is invalid.

The iostat argument is used to report whether an error, end-of-record,

or end-of-file condition (12.11) occurs. If an error condition

occurs, the defined input/output procedure shall assign a positive
value to the iostat argument. Otherwise, if an end-of-file condition
occurs, the defined input procedure shall assign the value of the

named constant IOSTAT_END (16.10.2.16) to the iostat argument.

Otherwise, if an end-of-record condition occurs, the defined input
procedure shall assign the value of the named constant IOSTAT_EOR

(16.10.2.17) to iostat. Otherwise, the defined input/output procedure

shall assign the value zero to the iostat argument.

The code does not set a postive value for iostat. An end-of-record
condition did not occur, so setting iostat to iostat_eor is incorrect
as it is not a positive value.

If the defined input/output procedure returns a nonzero value for the
iostat argument, the procedure shall also return an explanatory
message in the iomsg argument. Otherwise, the procedure shall not
change the value of the iomsg argument.

The code does not set iomsg.

QED

At a minimum, your code should look like

program p
use m
type(t) :: foo

integer i
character(len=42) msg
print *, iostat_eor
read(*,*,iostat=i,iomsg=msg) foo
if (i == 0) then
print *, "Hello World!"
else
print *, trim(msg)
end if
end program

where I'll leave the changes to read_t for to think about.

--
steve

[FortranFan]

On Thursday, December 21, 2017 at 1:17:39 AM UTC-5, kargl wrote:

> ..
>
> The code is invalid.
> ..
> The code does not set a postive value for iostat. ..
> ..

> The code does not set iomsg.

The above comments again totally miss the point the implementation really has an issue with failing to initiate error termination given what the standard states "If an error condition occurs during execution of an input/output statement that contains neither an ERR= nor IOSTAT= specifier, error termination is initiated." The case presented was just a quick, contrived attempt. Here's another one:

module m

type :: t
integer :: i = 0
end type

interface read(formatted)
module procedure read_t
end interface

contains

subroutine read_t( dtv, lun, iotype, v_list, iostat, iomsg )

class(t), intent(inout) :: dtv
integer, intent(in) :: lun
character(len=*), intent(in) :: iotype
integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(len=*), intent(inout) :: iomsg

select case ( iotype )

case ( "LISTDIRECTED" )

read( lun, fmt=*, iostat=iostat, iomsg=iomsg ) dtv%i

if ( iostat == 0 ) then
iostat = 1
iomsg = "iostat set to 1 just 'coz"
end if

case ( "DT" )
! elided

case ( "NAMELIST")
! elided

case default
! elided

end select

return

end subroutine

end module

program p

use m

type(t) :: foo

read(*,*) foo

print *, "foo%i = ", foo%i

stop 0

end program

Upon execution with Intel Fortran,

42
forrtl: severe (157): Program Exception - access violation
Image PC Routine Line Source

msvcrt.dll 000007FEFDB1716E Unknown Unknown Unknown
msvcrt.dll 000007FEFDB6A5D1 Unknown Unknown Unknown
p.exe 000000013FA87E7C Unknown Unknown Unknown
p.exe 000000013FA8593E Unknown Unknown Unknown
p.exe 000000013FAD261B Unknown Unknown Unknown
p.exe 000000013FA904FE Unknown Unknown Unknown
p.exe 000000013FA8E419 Unknown Unknown Unknown
p.exe 000000013FA814E0 MAIN__ 55 p.f90
p.exe 000000013FB36B12 Unknown Unknown Unknown
p.exe 000000013FB37564 Unknown Unknown Unknown
p.exe 000000013FB37487 Unknown Unknown Unknown
p.exe 000000013FB3734E Unknown Unknown Unknown
p.exe 000000013FB375D9 Unknown Unknown Unknown

kernel32.dll 00000000776659CD Unknown Unknown Unknown
ntdll.dll 000000007779A561 Unknown Unknown Unknown

But with gfortran,
42
foo%i = 42
STOP 0

[kargl]

FortranFan wrote:

> On Thursday, December 21, 2017 at 1:17:39 AM UTC-5, kargl wrote:
>
>> ..
>>
>> The code is invalid.
>> ..
>> The code does not set a postive value for iostat. ..
>> ..
>> The code does not set iomsg.
>
>
> The above comments again totally miss the point the implementation really has an issue with failing to initiate error termination given what the standard states "If an error condition occurs during execution of an input/output statement that contains neither an ERR= nor IOSTAT= specifier, error termination is initiated." The case presented was just a quick, contrived attempt. Here's another one:
>

Uh no, you missed the point. An error condition did not occur.

An end-of-record condition occurs when a nonadvancing input
statement attempts to transfer data from a position beyond
the end of the current record, unless the file is a stream
file and the current record is at the end of the file (an
end-of-file condition occurs instead).

Setting iostat to iostat_eor in your read_t is invalid. An end-of-record
condition did not occur! The read statement in read_t has successfully
read 42 from INPUT_UNIT. You elided the passage that I quoted. Here
it is again:

If an error condition occurs, the defined input/output procedure
shall assign a positive value to the iostat argument.

Otherwise, if an end-of-file condition occurs, the defined input
procedure shall assign the value of the named constant IOSTAT_END
(16.10.2.16) to the iostat argument.

Otherwise, if an end-of-record condition occurs, the defined input
procedure shall assign the value of the named constant IOSTAT_EOR
(16.10.2.17) to iostat. Otherwise, the defined input/output procedure
shall assign the value zero to the iostat argument.

Here the additional info you need:

The value of the default integer scalar constant IOSTAT_EOR is
assigned to the variable specified in an IOSTAT= specifier (12.11.5)
if an end-of-record condition occurs during execution of an input
statement and no end-of-file or error condition occurs. This value
shall be negative and different from the value of IOSTAT_END.

--
steve

[Dick Hendrickson]

On 12/21/17 1:03 AM, kargl wrote:
> FortranFan wrote:
>
>> On Thursday, December 21, 2017 at 1:17:39 AM UTC-5, kargl wrote:
>>
>>> ..
>>>
>>> The code is invalid.
>>> ..
>>> The code does not set a postive value for iostat. ..
>>> ..
>>> The code does not set iomsg.
>>
>>
>> The above comments again totally miss the point the implementation really has an issue with failing to initiate error termination given what the standard states "If an error condition occurs during execution of an input/output statement that contains neither an ERR= nor IOSTAT= specifier, error termination is initiated." The case presented was just a quick, contrived attempt. Here's another one:
>>
>
> Uh no, you missed the point. An error condition did not occur.
>
> An end-of-record condition occurs when a nonadvancing input
> statement attempts to transfer data from a position beyond
> the end of the current record, unless the file is a stream
> file and the current record is at the end of the file (an
> end-of-file condition occurs instead).
>
> Setting iostat to iostat_eor in your read_t is invalid.

I think you're wrong here, Steve. I think the legislative intent was
that the derived type I/O routines could do whatever they wanted with
the status return codes. They could look at the data and do the right
thing; including fixing-up errors or reporting errors based on the
values. There isn't even a requirement that the routines do any actual
I/O. That's sort of like a standard read statement returning "Card
Reader Is Off-line," it doesn't have to read a card.

(It would have been easier if Fortran Fan had initially set up an error
value for iostat, instead of the EOR value. EOR isn't an error an it
confused me a bit.)

Dick Hendrickson

[FortranFan]

On Thursday, December 21, 2017 at 11:08:15 AM UTC-5, Dick Hendrickson wrote:

> .. I think the legislative intent was

> that the derived type I/O routines could do whatever they wanted with
> the status return codes. They could look at the data and do the right
> thing; including fixing-up errors or reporting errors based on the
> values. There isn't even a requirement that the routines do any actual

> I/O. ..

Thanks to Dick Hendrickson for very nice insight into defined input and output, that is the gist I had picked up but from his own book (along with other coauthors), The Fortran 2003 Handbook, though I could never have summarized it as such.


> ..
> (It would have been easier if FortranFan had initially set up an error

> value for iostat, instead of the EOR value. EOR isn't an error an it
> confused me a bit.)

Agreed. As I mentioned upthread, what I set up earlier was a quick, contrived attempt at a potential issue I noticed with the implementation mentioned in the original post where the end-of-record was coming into play, but it *had* to be set as an error with a nonzero IOSTAT argument, and yet no error termination was initiated with the parent read when ERR= and IOSTAT= specifiers where absent.