(j3.2006) (SC22WG5.4369) WG5 informal ballot re Interop. TR

[Bill Long]

I am starting a 4-week informal WG5 ballot on this schedule and on N1838.
Please answer these questions by 9 a.m. UK time on 7 December.

1. Is the above revised schedule acceptable?

Yes.


2. Do you have any comments on N1838? Please give special attention
to the UTIs. For each significant change, please provide text for a new
UTI.


Regarding UTI TR3, I definitely do not like the current rank-expansion 
scheme in the TR. The main alternate options seem to be 1 (use elem_len) 
and 2 (add a new element length member).  I would argue that option 1 is 
better because:

1) From the Fortran program point of view, the length of the element of 
the array IS the len() of an element of the array for a character array. 
  This is the value proposed to be used as the elem_len member in the C 
descriptor.

2) A character length member in the descriptor is dead weight for all 
types except char.  And for the specific type of char, the elem_len for 
a single char is defined to be 1 (since the value is in units of size of 
char), so sticking 1 into the elem_len field provides no added information.

3) In many cases (especially in the MPI usage context) the objective is 
to just move a block of memory from one place to another.  With option 
1, there is noting special about the character len()>1 case as the 
appropriate number of bytes to move is the elem_len field value. With 
option 2, the user would have to check for type char and, for that case 
only, use the new field value to get the number of bytes to move per 
array element. (Nominally, it would be new_member*elem_len, but 
elem_len=1 for option 2.)  This seems like an unnecessary coding 
complication.


Cheers,
Bill


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