Thanks, Russ, for clarifying a few points for me; particularly, what
a "variable length character string" means. With these definitions,
Fortran supports arrays of fixed length character strings. I was probably
trying to say that it would be nice if this were part of a netcdf primitive,
perhaps a new "fixed-string" type that would map more directly to the
concept of a character variable in fortran. As you said:
>I guess I disagree. In Fortran, the string argument might be a vector or an
>array, since netCDF supports vector attributes and multidimensional array
>variables of various types, including character. Notice that if the
>variable STRING is declared in any of the following ways
>
> 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.
>...
> It would have been arguably simpler to leave the string length parameters
> out of the get calls and not check for whether the user provided enough
> space, but that would be a disservice in the case of attributes, where for
> safety the user would otherwise have to precede every get-attribute call
> with an attribute-inquire call to make sure the attribute value wasn't too
> large for the allocated space (as is necessary for the C interface). With
> the current Fortran interface, only one call is needed, and the user can
> find out from the results of the call whether the attribute value was larger
> than the space allocated. The string-length parameter is intended to be the
> space allocated for an attribute value, not the value returned by the LEN()
> function, which may be smaller in the case of a character array. The
> current documentation probably doesn't make this intended meaning of the
> string-length argument clear enough.
The size checking for fortran is fine, but with lengths passed implicitly
(not as prone to coding errors) this could continue to be done. Only one
call is needed in fortran currently, unless you want to be careful and
check either before or after for attribute overflow.
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.
Currently, the primitives: BYTE CHAR SHORT LONG FLOAT DOUBLE
have fixed byte storage: 1 1 2 4 4 8
with the dimensions defining a completely filled data structure. A
fixed-string data type would have a fixed (but arbitrary) byte length
and would also have dimensions defining a completely filled data structure.
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.
