(j3.2006) Adventures in sections of constant arrays
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:
character, parameter :: hello*(*) = 'Hello, world!'//achar(0)
end module constants
end subroutine trashme
end subroutine trashme2
end module funcs
end subroutine trashme3
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, 18.104.22.168 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...
More information about the J3