(j3.2006) Interop TR: Assumed-size actuals

Aleksandar Donev donev
Tue Nov 16 00:04:57 EST 2010


I finally found some time to look at the draft Interop TR. I can see 
that it is a unfinished product, but here are some questions/comments:

1. There is a whole lot of complication with an attempt to allow 
assumed-size arrays to be associated as actuals with assumed-rank 
dummies. Why is this really important? In particular, we don't go 
through such hoops for assumed-shape dummies, so why was it seen as 
important to start jumping through hoops now? For the shape, it is said 
it is [(size(array,i),i=1,rank(array))]. Should this not be rank-1? What 
is the size along the last dimension?

2. An assumed-type dummy shall not correspond to actuals of an "exotic" 
derived type (e.g., no type-bound procedures). Is this "dynamic type". 
If so, it seems allowed to have a CLASS(*) actual and not be able to 
verify anything until run-time: If the dynamic type is indeed exotic no 
one will notice and no errors will be generated.

3. There is some weird insistence that  the base_addr, elem_len and 
version be in that order?!? Why and if there actually is a good reason 
please put a note.

4. I personally hate the proposed "solution" for characters. When it 
comes to voting again, count me or alternative (1), making elem_len 
equal to the character length (and if we do add wchar_t we will have 
another type identifier, different from char, so I do not see what the 
problem would be).

5. Can someone please write an example of the macro CFI_DESC_T. The only 
ways I know involve union or malloc and I am not sure they can be used 
as type identifiers in declarations. I understand that one can make 
CFI_DESC_T(5) expand to some opaque block-of-enough-bytes, but that 
defeats the purpose since one can only use the object of type 
CFI_DESC_T(5) via pointers and casts, as done in the example in Note 
5.2, but one could not in fact do something like object.base_addr. Seems 
extremely clunky to me which is why I was opposed to flexible array members.

6. In the routine CFI_initialize_cdesc, presumably different things 
happen depending on whether it is assumed-shape, pointer or allocatable 
array, i.e., all the fields are properly initialized?

7. I made the point several times that a routine such as 
CFI_cdesc_to_bounds cannot be implemented. It only works for contiguous 
objects, since strides do not have to be integer multiples of the 
lem_length. At least Bill agreed with me and then promised to take it 
out but it is back in again, with unmodified wording.


Aleksandar Donev, Assistant Professor of Mathematics
Courant Institute of Mathematical Sciences
Office: 909 Warren Weaver Hall, New York University
E-mail: donev at courant.nyu.edu
Phone: (212) 992-7315; Fax: (212) 995-4121
Mailing address: 251 Mercer St, New York, NY 10012
Web: http://cims.nyu.edu/~donev

More information about the J3 mailing list