https://www.jiscmail.ac.uk/cgi-bin/webadmin?RSS&L=COMP-FORTRAN-90&v=1.0COMP-FORTRAN-90 List
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=COMP-FORTRAN-90
COMP-FORTRAN-90 List Archives2017-11-13T15:14:15ZPowered by L-Soft's LISTSERV mailing list manager
http://www.lsoft.com/products/listserv-powered.asp
http://www.lsoft.com/images/listserv_small.gifRe: Fortran 2015 -> Fortran 2018, Fortran 2020 -> Fortran 202x
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1baaf034.1711
On 11/12/2017 3:11 PM, Steve Lionel wrote:<br>> Document N2044 at the WG5<br>> web site (https://wg5-fortran.org) has details as well as comments from<br>> members.<br><br>Correction - N2144, not N2044. Also the link for N2144 was broken on the<br>web site, now fixed. My apologies.<br><br>Steve
2017-11-13T10:14:05-05:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1baaf034.1711Fortran 2015 -> Fortran 2018, Fortran 2020 -> Fortran 202x
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d3e152b3.1711
WG5 has polled its members and decided to change the informal name of<br>the next Fortran standard revision from "Fortran 2015" to "Fortran<br>2018", in order to reflect the year of publication. This puts Fortran in<br>the company of other language standards, and even has some history in<br>Fortran itself (Fortran 90 changed names three times, Fortran 2003 was<br>originally going to be called Fortran 2000. Document N2044 at the WG5<br>web site (https://wg5-fortran.org) has details as well as comments from<br>members. [...]
2017-11-12T15:13:33-05:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d3e152b3.1711Re: Misapplication of C1283 for pointer argument?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fde0c174.1711
On 11/10/2017 2:32 PM, Neil Carlson wrote:<br>> Thanks for pointing out those notes Steve. But they still leave me<br>> confused about this particular case. Perhaps I'm just being extra dense.<br>><br>> The set of all conceivable side effects from<br>><br>> integer, pointer :: a(:)<br>> [...]<br>> a = 1<br>><br>> appears to me to be a super set of all conceivable side effects from<br>> the more restrictive<br>><br>> integer, pointer, intent(in) :: a(:)<br>> [...]<br>> a = 1<br>><br>> Is that not true? Yet [...]
2017-11-10T14:50:04-05:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fde0c174.1711Re: Misapplication of C1283 for pointer argument?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d624e88b.1711
Thanks for pointing out those notes Steve. But they still leave me<br>confused about this particular case. Perhaps I'm just being extra dense.<br><br>The set of all conceivable side effects from<br><br>integer, pointer :: a(:)<br>[...]<br>a = 1<br><br>appears to me to be a super set of all conceivable side effects from the<br>more restrictive<br><br>integer, pointer, intent(in) :: a(:)<br>[...]<br>a = 1 [...]
2017-11-10T12:32:49-07:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d624e88b.1711Re: Misapplication of C1283 for pointer argument?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b547735e.1711
On Fri, Nov 10, 2017 at 11:41 AM, Neil Carlson <neil.n.carlson@gmail.com> wrote:<br>> ..<br>><br>> I'm trying to understand why this is a constraint (if indeed it was really<br>> intended to be a constraint).<br><br>The supposed exception when INTENT is omitted (or is INOUT) doesn't<br>make sense; perhaps someone can enlighten the readers. Because it<br>permits code with side effects such as: [...]
2017-11-10T14:23:25-05:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b547735e.1711Re: Misapplication of C1283 for pointer argument?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f138294c.1711
On 11/10/2017 11:41 AM, Neil Carlson wrote:<br>> I'm well aware that this is all about the PURE attribute.<br>><br>> On Fri, Nov 10, 2017 at 9:30 AM, Vipul Parekh <parekhvs@gmail.com<br>> <mailto:parekhvs@gmail.com>> wrote:<br>><br>> [...] Under<br>> the circumstances you show the target can be any object that<br>> ordinarily would not be permitted to appear in a variable definition<br>> context in a pure procedure, so the error makes sense.<br>><br>><br>> Except that without the INTENT it is allowed in a pure procedure.<br>><br>> I'm trying to understand why this is a constraint [...]
2017-11-10T12:10:26-05:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f138294c.1711Re: Misapplication of C1283 for pointer argument?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7fccb63d.1711
I'm well aware that this is all about the PURE attribute.<br><br>On Fri, Nov 10, 2017 at 9:30 AM, Vipul Parekh <parekhvs@gmail.com> wrote:<br><br>> [...] Under<br>> the circumstances you show the target can be any object that<br>> ordinarily would not be permitted to appear in a variable definition<br>> context in a pure procedure, so the error makes sense.<br>> [...]
2017-11-10T09:41:09-07:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7fccb63d.1711Re: Misapplication of C1283 for pointer argument?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2533beb0.1711
On Fri, Nov 10, 2017 at 9:52 AM, Neil Carlson <neil.n.carlson@gmail.com> wrote:<br>>..<br>><br>> The error messages are all to the effect of "a cannot appear in a variable<br>> definition context in a pure procedure". This language suggest C1283 (in<br>> F2008 12.7) as the basis for the error. I don't understand why this would<br>> be an error as the INTENT applies to the pointer and not its target, .. [...]
2017-11-10T11:30:39-05:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2533beb0.1711Misapplication of C1283 for pointer argument?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5318f3e4.1711
All three compilers I have access to object to the assignment statement in<br><br>pure subroutine foo(a)<br>integer, pointer, intent(in) :: a(:)<br>a = 1<br>end subroutine<br><br>Yet all are okay with<br><br>pure subroutine foo(a)<br>integer, pointer :: a(:)<br>a = 1<br>end subroutine<br><br>The error messages are all to the effect of "a cannot appear in a variable<br>definition context in a pure procedure". This language suggest C1283 (in<br>F2008 12.7) as the basis for the error. I don't understand why this would<br>be an error as the INTENT applies to the pointer and not its target, which<br>is what [...]
2017-11-10T07:52:28-07:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5318f3e4.1711Re: IEEE_COPY_SIGN - kinds of X and Y?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;cb8164ce.1711
Anton Shterenlikht wrote:<br>> 17.11.3 IEEE_COPY_SIGN in p3-4 says:<br>> "3. Arguments. The arguments shall be of type real.<br>> 4. Result Value. The result has the absolute value of X..."<br>><br>> It seems the kind of Y is not important, i.e.<br>> the kind of the result is the same as the kind of X.<br>> Also it seems there is no requirement that kinds<br>> of X and Y are the same. [...]
2017-11-08T16:34:17+00:00John Reidhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;cb8164ce.1711IEEE_COPY_SIGN - kinds of X and Y?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9f41c3ea.1711
17.11.3 IEEE_COPY_SIGN in p3-4 says:<br>"3. Arguments. The arguments shall be of type real.<br>4. Result Value. The result has the absolute value of X..."<br><br>It seems the kind of Y is not important, i.e.<br>the kind of the result is the same as the kind of X.<br>Also it seems there is no requirement that kinds<br>of X and Y are the same.<br>I guess it cannot matter. [...]
2017-11-08T16:18:54+00:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9f41c3ea.1711unsubscribe
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d6131831.1710
Full message available at: <a href="https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d6131831.1710">unsubscribe </a>2017-10-24T10:52:26+00:00Marcelus Glaucushttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d6131831.1710Re: TRANSFER and POINTER
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;77023d3b.1710
Malcolm,<br><br>Thanks for the additional information. I get your point about bounds, though in the case I’m currently encountering the targets are actually scalars. I’ll be happy to add to my documentation that the targets of the contained pointers are not permitted to overlap and other similar constraints. But as to the deeper issues ... [...]
2017-10-23T01:25:49+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;77023d3b.1710Re: TRANSFER and POINTER
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;97a19c92.1710
Not only is this not guaranteed by the standard, it is dis-guaranteed in<br>some situations.<br><br>For example, if you have two array pointers to the same array, so<br>ASSOCIATED(P1,P2), but the bounds of P1 and P2 are different, they will<br>obviously have different internal state.<br><br>Various compilers keep various information in pointers, especially<br>polymorphic and array pointers. For debugging it might well contain<br>information about how the pointer came about, when it was associated etc. [...]
2017-10-22T11:05:56+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;97a19c92.1710apologies for the near duplicates
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;65111765.1710
Fat thumbs and a flaky internet connection resulted in a draft being sent unintentionally.<br><br>Apologies.
2017-10-21T15:41:32+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;65111765.1710TRANSFER and POINTER
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e9527226.1710
Consider the following code snippet<br><br>TYPE :: FOO<br>INTEGER :: i<br>END TYPE FOO<br><br>TYPE :: WRAPPER<br>CLASS (FOO), pointer :: p<br>END TYPE WRAPPER<br><br>…<br><br>TYPE (WRAPPER) :: w1<br>TYPE (WRAPPER) :: w2<br><br>QUESTION: If ASSOCIATED(w1%p,w2%p) returns TRUE, is the following expression guaranteed to return TRUE?<br><br>ALL(TRANSFER(w1,[1]) == TRANSFER(w2,[1]))<br><br>The idea is that if the pointers have the same target then their internal structure should be the same. TRANSFER then exposes that as an integer array in an opaque manner. Simple examples with all of the compilers I use return TRUE, but a more complex example returns FALSE for [...]
2017-10-21T15:39:55+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e9527226.1710Unsuscribe
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;20545097.1710
Full message available at: <a href="https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;20545097.1710">Unsuscribe </a>2017-10-19T23:12:30+02:00Álvaro Franganillohttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;20545097.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1e13d456.1710
On Mon, Oct 16, 2017 at 3:14 PM, Van Snyder <van.snyder@jpl.nasa.gov> wrote:<br><br>> On Mon, 2017-10-16 at 08:22 +0000, Hambley, Matthew wrote:<br>> > You might expect that an undefined<br>> > pointer would be, by definition, unassociated but that is not the way<br>> > the standard is written.<br>><br>> The standard is not written that way because it cannot be written that<br>> way. Consider (assuming A and B are rank-one arrays):<br>><br>> allocate ( A(10) )<br>> B => A(3:7:2)<br>> deallocate ( A )<br>><br>> B is undefined. It is unreasonable to expect [...]
2017-10-16T19:37:26-05:00Dick Hendricksonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1e13d456.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7206dece.1710
On Mon, 2017-10-16 at 08:22 +0000, Hambley, Matthew wrote:<br>> You might expect that an undefined<br>> pointer would be, by definition, unassociated but that is not the way<br>> the standard is written.<br><br>The standard is not written that way because it cannot be written that<br>way. Consider (assuming A and B are rank-one arrays): [...]
2017-10-16T13:14:13-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7206dece.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1263029d.1710
Hambley, Matthew wrote:<br>> From: Fortran 90 List [mailto:COMP-FORTRAN-90@JISCMAIL.AC.UK] On Behalf<br>>><br>>> Given the discussion thus far on subobjects, is the following code<br>>> standard-conforming?<br>>><br>>> module m<br>>><br>>> type :: t<br>>> type(t), pointer :: i => null()<br>>> end type<br>>><br>>> contains<br>>><br>>> subroutine sub( o1, o2 )<br>>> type(t), pointer, intent(in) :: o1<br>>> type(t), pointer, intent(in) :: o2<br>>> if ( associated(o2) ) print *, "In sub, o2 is associated"<br>>> o1%i => null()<br>><br>> You could try playing with the "nullify" statement to achieve the same<br>> thing. I'm [...]
2017-10-16T10:14:27+01:00John Reidhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1263029d.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;24c9472b.1710
From: Fortran 90 List [mailto:COMP-FORTRAN-90@JISCMAIL.AC.UK] On Behalf<br>><br>> Given the discussion thus far on subobjects, is the following code<br>> standard-conforming?<br>><br>> module m<br>><br>> type :: t<br>> type(t), pointer :: i => null()<br>> end type<br>><br>> contains<br>><br>> subroutine sub( o1, o2 )<br>> type(t), pointer, intent(in) :: o1<br>> type(t), pointer, intent(in) :: o2<br>> if ( associated(o2) ) print *, "In sub, o2 is associated"<br>> o1%i => null() [...]
2017-10-16T08:22:13+00:00Hambley, Matthewhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;24c9472b.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1300d586.1710
On 10/13/2017 6:08 PM, Vipul Parekh wrote:<br>> Given the discussion thus far on subobjects, is the following code<br>> standard-conforming?<br>><br><br>I believe so. Perhaps you're wondering about the "side-effect" on o2<br>from nullifying o1%i, even though o2 is a pointer with INTENT(IN).<br><br>First, INTENT(IN) restricts the contexts in which a dummy argument with<br>that attribute may appear. o2 does not appear in the forbidden contexts. [...]
2017-10-14T10:29:38-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1300d586.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7df92d0f.1710
Given the discussion thus far on subobjects, is the following code<br>standard-conforming?<br><br>module m<br><br>type :: t<br>type(t), pointer :: i => null()<br>end type<br><br>contains<br><br>subroutine sub( o1, o2 )<br>type(t), pointer, intent(in) :: o1<br>type(t), pointer, intent(in) :: o2<br>if ( associated(o2) ) print *, "In sub, o2 is associated"<br>o1%i => null()<br>if ( .not. associated(o2) ) print *, "And now o2 is not associated"<br>end subroutine [...]
2017-10-13T18:08:18-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7df92d0f.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a6b62556.1710
I was careless and just looked at the definition of subobject (in the terms list) which says a “subobject” is<br><br>" • portion of data object that can be referenced, and if it is a variable defined, independently of any other portion”<br><br>Cheers,<br>Bill<br><br>> On Oct 11, 2017, at 10:45 PM, Malcolm Cohen <malcolm@NAG-J.CO.JP> wrote:<br>><br>> No it does not say that. O%I is ***NOT*** a subobject of O. This is FUNDAMENTAL.<br>><br>> Here is what the standard says:<br>> " A data-ref with more than one part-ref is a subobject of its base object if none [...]
2017-10-12T05:27:17+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a6b62556.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ba422d47.1710
No it does not say that. O%I is ***NOT*** a subobject of O. This is FUNDAMENTAL.<br><br>Here is what the standard says:<br>" A data-ref with more than one part-ref is a subobject of its base object if none of the part-names, except for possibly the rightmost, is a pointer."<br><br>In the case of O%I, the part-ref "O" is a pointer, and is not the rightmost part-ref. Therefore O%I is not a subobject of O. [...]
2017-10-12T12:45:48+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ba422d47.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8775a7bd.1710
This part of the INTENT subclause might be confusing, though:<br><br>"If an object has an INTENT attribute, then all of its subobjects have the same INTENT attribute.”<br><br>This seems to say that the component pointer has the INTENT(IN) attribute.<br><br>Cheers,<br>Bill<br><br>> On Oct 11, 2017, at 7:28 PM, Malcolm Cohen <malcolm@NAG-J.CO.JP> wrote:<br>><br>> Yes the code is standard-conforming.<br>><br>> Steve Lionel writes:<br>>> It is not. Note 5.16 even gives an explicit example of this:<br>><br>> Steve has missed the fact that the dummy argument is itself a pointer, so INTENT(IN) applies to the pointer dummy, [...]
2017-10-12T02:56:17+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8775a7bd.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2a988e29.1710
On 10/11/2017 8:28 PM, Malcolm Cohen wrote:<br>> Steve Lionel writes:<br>>> It is not. Note 5.16 even gives an explicit example of this:<br>> Steve has missed the fact that the dummy argument is itself a pointer, so INTENT(IN) applies to the pointer dummy, not to the pointer component of its target.<br>><br>Oh.. I think I get it now. I didn't miss that the dummy was a pointer<br>but I DID miss that o%i references the target of o, and thus 96:9<br>doesn't apply. You're right, that is subtle and better words would help. [...]
2017-10-11T20:34:56-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2a988e29.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3f0c326e.1710
Yes the code is standard-conforming.<br><br>Steve Lionel writes:<br>> It is not. Note 5.16 even gives an explicit example of this:<br><br>Steve has missed the fact that the dummy argument is itself a pointer, so INTENT(IN) applies to the pointer dummy, not to the pointer component of its target.<br><br>>NOTE 5.16<br>>If a dummy argument is a derived-type object with a pointer component, then the pointer as a pointer is a subobject of the dummy >argument, but the target of the pointer is not. [...]
2017-10-12T09:28:17+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3f0c326e.1710Re: A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;bcb1786.1710
On 10/11/2017 10:40 AM, Vipul Parekh wrote:<br>> Is the following simple code standard-conforming?<br>><br>> module m<br>><br>> type :: t<br>> integer, pointer :: i<br>> end type<br>><br>> contains<br>><br>> subroutine sub( o )<br>> type(t), pointer, intent(in) :: o<br>> !o => null() !<--- A<br>> o%i => null() !<--- B<br>> end subroutine<br>><br>> end module<br>><br>It is not. Note 5.16 even gives an explicit example of this: [...]
2017-10-11T15:05:39-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;bcb1786.1710A question on pointer association context of a POINTER subobject of a dummy argument with POINTER as well as INTENT(IN) attribute
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;eec78802.1710
Is the following simple code standard-conforming?<br><br>module m<br><br>type :: t<br>integer, pointer :: i<br>end type<br><br>contains<br><br>subroutine sub( o )<br>type(t), pointer, intent(in) :: o<br>!o => null() !<--- A<br>o%i => null() !<--- B<br>end subroutine<br><br>end module<br><br>Please notice the POINTER as well as INTENT(IN) attribute of dummy<br>argument o. Now note the instruction marked B above. A subobject of<br>this dummy argument o which also has the POINTER attribute appears in<br>a pointer association context. Two compilers I tried do not raise and<br>errors or warnings about this but is this conformant with the<br>standard? [...]
2017-10-11T10:40:02-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;eec78802.1710