Errata list for "Modern Fortran Explained"

[michael...@compuserve.com]

Since "Modern Fortran Explained" was published two years ago a number of errors have been detetected, sometimes by contributors to this newsgroup (to whom our thanks).

An errata list has now been prepared, and is available at ftp://ftp.numerical.rl.ac.uk/pub/MRandC/edits.pdf.

Regards,

Mike Metcalf

[invalid]

Well done. I picked up a copy of your book. 2 sparse pages of errata for
three years and not much at all since the 2nd printing. Quite good!

[michael...@compuserve.com]

This post triggered a number of error reports from readers and the errata file has been modified accordingly. The most important change is to the extended OO example in Appendix E: ftp://ftp.numerical.rl.ac.uk/pub/MRandC/oo.f90. Here the following edits were required:

439/1: Delete line "item%prevptr%prevptr => ..."
439/-2: After "(anylist)" add ", target".

Clearly, compilers have improved since this code was originaaly tested over two years ago, and we would like to think that this revised version could be of use in F2003 test suites.

Regards,

Mike Metcalf

[michael...@compuserve.com]

Am Dienstag, 16. April 2013 10:39:00 UTC+2 schrieb michael...@compuserve.com:
> Since "Modern Fortran Explained" was published two years ago a number of errors have been detetected, sometimes by contributors to this newsgroup (to whom our thanks). An errata list has now been prepared, and is available at ftp://ftp.numerical.rl.ac.uk/pub/MRandC/edits.pdf. Regards, Mike Metcalf

Please note that this file has again been updated:

ftp://ftp.numerical.rl.ac.uk/pub/MRandC/edits.pdf

Regards,

Mike Metcalf

[FortranFan]

Mike,

Re: the extended OO example in Appendix E of this book, can you please confirm there have been no further edits to the code since your note dated 5th of June, 2013?


Please note Intel Fortran fails during execution of the code available currently at ftp://ftp.numerical.rl.ac.uk/pub/MRandC/oo.f90. The failure mode is "access violation" error at line "deallocate(temp)" in subroutine delete. You can see a discussion on this error at the Intel Fortran forum: https://software.intel.com/en-us/forums/topic/518263.

Note the comments by the astute and brilliant reader "yamajun" who says the line preceding the deallocate(temp) statement should read "call remove(temp)" instead of "call remove(item)":

----------
yamajun Sat, 07/19/2014 - 16:18

I met the same problem with Intel Fortran v.14.0 last autumn. I'm curious about this problem, too.


Anyway there is something wrong with SUBROUTINE DELETE.

!
! Delete an item: removes it from the list and deallocates it.
!
subroutine delete(item)
class(anyitem), target :: item
class(anyitem), pointer :: temp
temp => item
call remove(item)
deallocate (temp)
end subroutine

If "temp" is removed instead of "item" as below, the program runs without problem.

!
! Delete an item: removes it from the list and deallocates it.
!
subroutine delete(item)
class(anyitem), intent(in), target :: item
class(anyitem), pointer :: temp
temp => item
call remove(temp)
deallocate (temp)
end subroutine


The cause of crash is in SUBROUTINE REMOVE (called by SUBROUTINE DELETE_LIST by way of SUBROUTINE DELETE ).

else if (associated(list%firstptr, item)) then
! First item in list.
list%firstptr => item%nextptr ! first = next.
item%nextptr%prevptr => item%prevptr ! next%prev = last.
end if
end if
nullify(item%upptr)


Dummy argument "item" is alias to"list%firstptr" ( actual argument of SUBROUTINE DELETE_LIST). This means the "first = next" line "list%firstptr => item%nextptr" is the same as "item => item%nextptr". So nullify(item%upptr), which should nullify 'first'%upptr, nullifies 'next'%upptr instead. But using "temp" as actual argument in DELETE avoids this problem.

This is quite confusing for me and I'm not sure whether this is the correct behavior of pointers or not.

http://fortran66.hatenablog.com/entry/2013/11/04/210236

----------

Can you please comment on yamajun's findings?

Also, re: your statement, "this code was originaaly tested over two years ago" - can you please provide details on how and where with which compiler was this testing performed?

Thanks much.

Kind Regards,

[michael...@compuserve.com]

Le mardi 22 juillet 2014 22:34:10 UTC+2, FortranFan a écrit :
> On Wednesday, September 18, 2013 4:16:11 AM UTC-4, michael...@compuserve.com wrote: > Am Dienstag, 16. April 2013 10:39:00 UTC+2 schrieb michael...@compuserve.com: > > > Since "Modern Fortran Explained" was published two years ago a number of errors have been detetected, sometimes by contributors to this newsgroup (to whom our thanks). An errata list has now been prepared, and is available at ftp://ftp.numerical.rl.ac.uk/pub/MRandC/edits.pdf. Regards, Mike Metcalf > > > > Please note that this file has again been updated: > > > > ftp://ftp.numerical.rl.ac.uk/pub/MRandC/edits.pdf > > > > Regards, > > > > Mike Metcalf Mike, Re: the extended OO example in Appendix E of this book, can you please confirm there have been no further edits to the code since your note dated 5th of June, 2013?

Dear FortranFan,
Unfortunately, I'm away from base for three weeks so will have to try to get a reply to you by other means. However, I note that at ftp://ftp.numerical.rl.ac.uk/pub/MRandC/ the most recent version of edits.pdf is 24 March, 2013 and the most recent version of oo.f90 is 30 October, 2013.

Watch this space.

Regards,

Mike Metcalf

[michael...@compuserve.com]

Correction: 24 March, 2014

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

On Tuesday, 22 July 2014 22:34:10 UTC+2, FortranFan wrote:
> On Wednesday, September 18, 2013 4:16:11 AM UTC-4, michael...@compuserve.com wrote:

Dear All,

....snip....

If this change is made:

>
> subroutine delete(item)
>
> class(anyitem), target :: item
>
> class(anyitem), pointer :: temp
>
> temp => item
>
> call remove(item)
>
> deallocate (temp)
>
> end subroutine
>
>
>
> If "temp" is removed instead of "item" as below, the program runs without problem.
>

gfortran still fails. It appears that although class(*) variables work as characters and are tested in the testsuite, it seems that class(*) components bomb-out totally. The substring reference is not recognised and, even if that is removed, the programme fails at run-time.

The good news is that once character list members are removed, together with the substring reference, the programme runs fine with gfortran. Thus the basic implementation of unlimited polymorphic components is working OK but "stringiness" is not.

I will isolate a reduced testcase and will raise a bug report.

Thanks for bringing this to my attention.

Paul

[FortranFan]

Paul,

Which version of gfortran are you using? It is unclear to me from your post - did you apply the changes suggested by "yamajun" i.e., change line to "call remove(temp)" to get the example to work or no?

I tried gfortran 4.9 and ran into 2 issues:

1) "select type" construct in the print function is unable to handle "type is (character(len=*)" case. This seems to have been identified as a known gfortran bug - see here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901

2) if the code relevant to issue in 1) is commented out, then functions returning data pointers such as "append" cause a segmentation fault during execution.

Thanks much,

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

> Which version of gfortran are you using? It is unclear to me from your post - did you apply the changes suggested by "yamajun" i.e., change line to "call remove(temp)" to get the example to work or no?

I said so - yes

>
>
>
> I tried gfortran 4.9 and ran into 2 issues:

I used 4.10 but 4.9 should behave in the smae way.

>
>
>
> 1) "select type" construct in the print function is unable to handle "type is (character(len=*)" case. This seems to have been identified as a known gfortran bug - see here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901

This is what I said - class(*) components of derived types have a problem with strings.

> 2) if the code relevant to issue in 1) is commented out, then functions returning data pointers such as "append" cause a segmentation fault during execution.

Please read what I said - replace the string list members with any other type and the code will compile and run correctly.

Regards

Paul

[michael...@compuserve.com]

> Unfortunately, I'm away from base for three weeks so will have to try to get a reply to you by other means. However, I note that at ftp://ftp.numerical.rl.ac.uk/pub/MRandC/ the most recent version of edits.pdf is 24 March, 2013 and the most recent version of oo.f90 is 30 October, 2014.
>
>
>
> Watch this space.
>
I'm sorry that it has taken so long to reply definitively to your message,
but holidays are now drawing to a close and I hope the following clarifies
the situation. In fact, several corrections to oo.f90 are called for, and
maybe I could ask you to post them too on the intel site.

Firstly, we do not agree with yamajun when he says

> Dummy argument "item" is alias to "list%firstptr"
> (actual argument of SUBROUTINE DELETE_LIST).

They are not aliases - they are pointers with the same target. Also

> This means the line

> "list%firstptr => item%nextptr" is the same as
> "item => item%nextptr".

Again no, as this is just changing the target of list%firstptr.

Unfortunately, there is no explanation of why temp is needed in subroutine
delete. It is because a passed-object dummy argument is not allowed to be a
pointer. However, we assume that item was created by allocation of a
pointer target and want to deallocate it. Hence the use of the pointer
temp that points to it.

But, in fact, it turns out that subroutine delete is anyway wrong, although
it will work on most if not all compilers.
The reason is that you should not be able to
destroy a dummy argument, although the standard contains no such actual
prohibition (something we will follow up). Taking account of all this, the
following changes ensure that it should work in all circumstances. The
downloadable code has been updated at ftp://ftp.numerical.rl.ac.uk/pub/MRandC/oo.f90.


433:-3 Add "delete," after "anyitem,".

434:middle. Change line
procedure, non_overridable :: delete
to
! delete has a pointer argument so cannot be type bound

437: a third of the way down. Change lines

class(anyitem), target :: item
class(anyitem), pointer :: temp
temp => item
call remove(item)
deallocate (temp)

to
! We want to deallocate the dummy argument, so it must be a pointer.
! It follows that the procedure cannot be a type-bound procedure.
class(anyitem), pointer :: item
call remove(item)
deallocate (item)

440:middle. Change line
call p%delete
to
call delete(p)


Thank you for drawing this to our attention.

Mike Metcalf