[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-20 16:47:56 UTC ---
(In reply to comment #2)
> I don't really understand this. Why should one allow it for unallocated
> allocatables, but not for undefined pointers?

Well, the situation for an unassociated pointer and for an unallocated
allocatable is the same: You know that it does not have a dynamic type -- and
you can check for this state via "<array>.data == NULL" or "<scalar> == NULL".

In case of an undefined pointer, you cannot. Thus, not allowing undefined
pointers anywhere makes sense.


The initially proposed wording was did not allow for notallocated
allocatables/notassociated pointers
(http://www.j3-fortran.org/doc/year/06/06-166.txt) but during the meeting 176
meeting the wording of 06-166 was changed (in two revisions, r1 and r2) to what
we have today; cf.
http://www.j3-fortran.org/doc/meeting/176/06-166r2.txt.

Unfortunately, the new version does not clearly tell what the result value
should be in that case. Possible choices would be: (a) storage size of the
declared type or (b) "zero" or the size of the class container.

If (b) is the correct answer, I do not see the reason for the additional
restrictions for types with "deferred type parameters" and for "unlimited
polymorphic" - one could simply return the same as for an unallocated
polymorphic.

Thus, I assume that (a) is meant, but I do not see how one can read this from
the standard (as opposed to guessing it).

Let's see what the J3 members think how it should be interpreted; I think
ultimately an interpretation request is required.