(j3.2006) Adventures in sections of constant arrays

Steve Lionel steve
Mon Mar 6 15:31:52 EST 2017


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
   contains
      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, 15.5.2.4 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.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170306/04e48261/attachment.html 



More information about the J3 mailing list