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

[Aleksandar Donev]

Hello,

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.

Thanks,
Aleks

-- 
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