Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

unprotected_pointer => protected_pointer

0 views
Skip to first unread message

Steven Correll

unread,
Sep 12, 2008, 1:25:32 PM9/12/08
to
Looking at N1601.pdf, I see

R735 pointer-assignment-stmt is data-pointer-object [ (bounds-spec-
list) ] => data-target
or data-pointer-object (bounds-remapping-list ) => data-target
or proc-pointer-object => proc-target

And I see constraint C538:

"A pointer object that has the PROTECTED attribute and is accessed by
use association shall
not appear as (1) A pointer-object in a pointer-assignment-stmt..."

C538 doesn't forbid using a protected pointer as the target of a
pointer-assignment-stmt. But two (gfortran 4.4.0, Sun f90 8.3) out of
three compilers surveyed (ifort 10.1 is the third) disallow it. Am I
overlooking something? Thanks in advance.

% cat p1.f90
module m
implicit none
integer, pointer, protected :: protected_pointer
end module m

program p
use m
implicit none
integer, pointer :: unprotected_pointer
unprotected_pointer => protected_pointer
end program p

% gfortran p1.f90
p1.f90:10.25:

unprotected_pointer => protected_pointer
1
Error: Pointer assignment target has PROTECTED attribute at (1)

% f90 p1.f90

unprotected_pointer => protected_pointer
^
"p1.f90", Line = 10, Column = 26: ERROR: The variable
"PROTECTED_POINTER" has the PROTECTED attribute and shall not appear
as the data-target or proc-target in a pointer-assignment statement.


Richard Maine

unread,
Sep 12, 2008, 3:38:16 PM9/12/08
to
Steven Correll <steven....@gmail.com> wrote:

> "A pointer object that has the PROTECTED attribute and is accessed by
> use association shall
> not appear as (1) A pointer-object in a pointer-assignment-stmt..."
>
> C538 doesn't forbid using a protected pointer as the target of a
> pointer-assignment-stmt. But two (gfortran 4.4.0, Sun f90 8.3) out of
> three compilers surveyed (ifort 10.1 is the third) disallow it. Am I
> overlooking something?

I don't think you are overlooking anything. Seems to me like those two
compilers are though. C537 prohibits a protected nonpointer object from
being a target. Looks to me like those compilers overlooked the
"nonpointer" part.

The distinction makes sense (to me). If you set a pointer to point to a
nonpointer protected target, you would have just opened a potential way
for that protected object to be changed, possibly in contexts that are
impractical for the compiler to diagnose, thus subverting much of the
point of the protected attribute.

But when a pointer is used as the data-target or proc-target in a
pointer assignment statement, you don't get anything pointing to that
pointer (in fact, you can't even have a pointer actually point directly
to another pointer). The pointer on the LHS of the assignment ends up
pointing to the same target as the pointer on the RHS. But that's ok, as
it doesn't open a way to change the protected thing, which was the
pointer, not its target.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Tobias Burnus

unread,
Sep 26, 2008, 12:10:17 PM9/26/08
to
On Sep 12, 9:38 pm, nos...@see.signature (Richard Maine) wrote:

> Steven Correll <steven.corr...@gmail.com> wrote:
> > "A pointer object that has the PROTECTED attribute and is accessed by
> > use association shall
> > not appear as (1) A pointer-object in a pointer-assignment-stmt..."
>
> > C538 doesn't forbid using a protected pointer as the target of a
> > pointer-assignment-stmt. But two (gfortran 4.4.0, Sun f90 8.3) out of
> > three compilers surveyed  (ifort 10.1 is the third) disallow it. Am I
> > overlooking something?
>
> I don't think you are overlooking anything. Seems to me like those two
> compilers are though. C537 prohibits a protected nonpointer object from
> being a target. Looks to me like those compilers overlooked the
> "nonpointer" part.

Thanks for the bugreport. This is now fixed in the GCC developer
release (4.4 alias trunk) and in the stable 4.3 branch.

Tobias

PS: In order to make sure that such messages are not overlooked,
please report those to GCC's Bugzilla next time.

0 new messages