String extension to netCDF

• To: pack@xxxxxxxxxxxx
• Subject: String extension to netCDF
• From: Russ Rew <russ>
• Date: Mon, 29 Jul 1991 07:55:37 -0600

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

• References:
  • RE: String extension to netCDF
    • From: Daniel Packman