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

[Bill Long]

Hi Aleks,

Thanks for reading through the draft.


On 11/15/10 11:04 PM, Aleksandar Donev wrote:
> 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?
>

The MPI people asked for this.  If you write the interface routine for 
an MPI routine and make the buffer argument assumed-rank, the previous 
spec had problems if the corresponding actual argument was assumed-shape.


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

Typically dope vectors have the base address as the first member (no 
extra indexing needed to access it that way) and it is common to have 
the element length next (it is the same length as the address and so 
plays well with alignment).  We put the version next because you need to 
know WHERE the version is located in the structure if you want to be 
able to use its value to determine the layout of the rest of the 
descriptor.


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

Your input is duly noted. (FWIW, I agree with you.)

[Need to catch a plane - will try to answer more in another email.]

Cheers,
Bill

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

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101