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 ...
Cheers
Reinhold
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
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/397248ff/attachment-0001.html