(j3.2006) Adventures in sections of constant arrays

Bader, Reinhold Reinhold.Bader
Mon Mar 6 16:07:05 EST 2017

The NAG compiler also produces a segfault for this code. I would argue that section 5.3.10 para 5 of 007, which reads

?If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of its effective argument (12.5.2).?

causes this to be invalid, though in a way not very obvious to the programmer (since the argument passing mechanism is not
determined by the standard). On the other hand, the above can be interpreted as a restriction on both the processor and the program ...


Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] Im Auftrag von Steve Lionel
Gesendet: Montag, 6. M?rz 2017 21:32
An: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Betreff: (j3.2006) Adventures in sections of constant arrays

Consider the following program, submitted by James VanBuskirk:

module constants

   implicit none

   character, parameter :: hello*(*) = 'Hello, world!'//achar(0)

end module constants

module funcs

   implicit none


      subroutine trashme(string,length)

         integer length

         character string(length)

         call trashme2(string(:length:2))

         write(*,'(*(g0))') string(:length)

      end subroutine trashme

      subroutine trashme2(array)

         character array(:)

         call trashme3(array)

      end subroutine trashme2

end module funcs

subroutine trashme3(array)

   implicit none

   character array(*)

end subroutine trashme3

program test

   use constants

   use funcs

   implicit none

   call trashme(hello, index(hello,achar(0))-1)

end program test

The main program passes a character constant to procedure trashme, which accepts it as an explicit-shape array of characters. This is allowed (17-007, p3-4.) trashme then passes a discontiguous array section to trashme2, which declares the dummy argument as a deferred-shape array of single characters.  trashme2 then passes its argument to trashme3, where the corresponding dummy is an assumed-size character array (also allowed). Because an assumed-size array must be contiguous, the processor has to check whether the actual argument is contiguous, and if not (which it isn't here), do copy-in/copy-out. It's the copy-out that gets us into trouble.

If trashme3's dummy had INTENT(INOUT) or INTENT(OUT), the associated actual argument must be definable, which it isn't here. But since there is no INTENT, that restriction does not apply. Because trashme3 might redefine the dummy, the copy has to be written back to the actual on return from trashme3 - but as it's a constant, that (typically) produces a segfault/access violation.

I haven't been able to find any language in the standard that this code violates, yet I also can't figure out how a compiler could possibly support it. Did I miss a trick somewhere? If the standard indeed does not prohibit this code, should it - and how should such a restriction be worded? It couldn't be a constraint. Note that the array never gets redefined here, so it can't be a restriction on redefinition.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170306/397248ff/attachment-0001.html 

More information about the J3 mailing list