> >
> > CHARACTER*1 S(100)
> > CHARACTER*10 T(10)
> > CHARACTER*100 U
> >
> >... Hence the value of LEN(ARG) is useless to
> >determine whether enough space has been allocated for the characters to be
> >returned.
>
> Indeed the len() function returns a different number for each of these
> examples. But although these represent the same *storage* allocation,
> they are not equivalent in useage. The convention in fortran netcdf calls
> could be to use the last representation (character*strlen) to allow allocated
> space to be passed implicitly.
Perhaps this would have been a good convention to use initially, but it also
seems possible that adopting it now might break a significant amount of
Fortran code that uses the first convention (CHARACTER S(strlen) instead of
CHARACTER*strlen S) or that uses multidimensional arrays of characters
(CHARACTER*strlen T(NUM)) as actual arguments in netCDF calls. I think the
utility of the latter justifies the current interface, even though users
sometimes have to provide redundant information when dealing with a single
string.
> I suppose my thinking is warped by a Fortran-centered view of fixed arrays
> of strings. In this narrow current view, it would be nice to either include
> a primitive for fixed strings or modify the current concept of char. The
> former is more attractive to avoid breaking old code.
We have tried to keep the C and Fortran interfaces parallel. Occasionally
this means using a lowest-comon-denominator approach (e.g. character arrays)
that is not ideal for either C or Fortran. Another goal is to permit the
same netCDF files to be written from either language interface or read from
either interface. If I understand it correctly, the primitives for fixed
strings you propose would be useful solely for the Fortran interface, and
the C interface would have to change to be able to access such data. I
think a more detailed interface proposal is necessary to permit us to
evaluate the benefits and costs of such a change.
> If the documentation (V1.11, page 23-24) is any indication, there are
> plans afoot for "a new type for multibyte characters". Perhaps someone
> knows if this new anticipated primitive is motivated by multinational
> character sets (often two bytes) and if it will look like a "fixed string"
> data type as I have discussed.
This was anticipated for the wide characters required for
internationalization.
--Russ
