Friedrich Hertweck said:
>William F Mitchell schrieb:
>>With intent(in) the compiler can assume the argument will not be changed.
>>If the user overrules it as you suggest, then the program is not standard
>>conforming.
>
>I have not found any rule that prohibits this.  In a pointer assignment
>definition there is no constraint to that effect

Programs must obey all rules in the standard, not just the constraints.
The only thing special about the constraints is that the compiler is
required to diagnose their violation.

5.1.2.3 states
"The INTENT(IN) attribute specifies that the dummy argument shall neither be
 defined nor become undefined during the execution of the procedure."

i.e. no matter with how much trickery you hide the fact from the compiler,
you just are not allowed to alter the value of INTENT(IN) dummy arguments
during that procedure's execution.  But the compiler need not complain - it
can start WW3 instead.

[...]
>As far as I can see, the production of undefined pointers is
>standard-conforming,

Yes indeed it is; but all you can do with them is pointer-assign them to
other pointers, you are not allowed to reference or deallocate them.

...again, the compiler need not diagnose any error you make.

>It is not only the interface: the function result is a pointer-assignment.
>A function like that does NOT make sense if it returns an undefined pointer.

It might not make sense to you (or indeed to me), but pointer functions are
perfectly entitled to return undefined pointers.  It is up to the user not
to do anything harmful with them.

>Here is an improved
>version of the function RES2 which will NOT accept the result of the RESHAPE:
>
>     function ptr(a,n1,n2)
>        integer, pointer :: ptr(:,:)
>        integer :: n1, n2
>        integer, target, INTENT(INOUT) :: a(n1,n2)
>
>        ptr => a
>     end function
>
>The INTENT(INOUT) makes sure that the actual argument   a(n1,n2)   cannot be
>an expression (or, which is basically the same, an indexed array section).

No it does not.  It does make sure it cannot be an expression, but an
array section is perfectly acceptable; the compiler will almost
certainly generate a copy-in copy-out in this case (which will result
in "ptr" being unusable).

>When the actual argument corresponding to  a(n1,n2)  does not have the TARGET
>attribute, the function permits a pointer to be assigned to a non-target
>object, which moreover violates the rule that a pointer shall only be
>assigned to a target of  the same type,
>kind type parameters, and rank (sec. 7.5.2  -  Pointer assignment).

>I do not feel uncomfortable with this situation

I agree - this is not very nice at all.

>So I maintain my position that a good compiler should be able to check on
>these things.

This would certainly be nice; I don't know of any that do as yet - we've
added quite a few inter-procedural checks recently but we don't yet spot
these particular problems with pointers.

The problem here is that the standard wording is vague:  the facility is
>supposed to be PROCESSOR DEPENDENT, so the user must check it.

Hmm, I think that the problems here are such that a user is not meant to
use it.  The processor dependency is not necessarily checkable (it may
vary unpredictably - the user cannot rely on a check in one instance
meaning that it will work in future calls).

>> On Linux, your program works as expected ...
>
>That is good to know

With a sufficiently checking compiler, your program would cease to work
because of the undefined pointer.
With a sufficiently optimising compiler, your program would give the
result you expect but more complicated "real" programs would give
results you would not expect because of the unexpected (and invalid)
aliasing you have set up.

My summary: just don't do this folks.  It's too complicated, you'll
probably shoot yourselves in the foot.

Cheers,
-- 
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
                           ([log in to unmask])


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%