(j3.2006) (SC22WG5.4369) WG5 informal ballot re Interop. TR
Mon Dec 6 08:07:06 EST 2010
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?
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
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
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
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
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
More information about the J3