RE: string types

• To: netcdfgroup@xxxxxxxxxxxxxxxx
• Subject: RE: string types
• From: pack@xxxxxxxxxxxx (Daniel Packman)
• Date: Mon, 24 Jun 1991 15:43:12 -0600

  [re - new string data type primitive]
>> The internal storage of such an object could be driven by the c language,
>> that is, a series of bytes terminated by a zero byte.  The mapping to
>> a fortran character variable that responds properly to the len()
>> intrinsic is clear.

>The underlying system has a "NC_STRING" datatype, and the underlying
>system support arrays of XXX, where XXX is NC_BYTE, NC_CHAR...
>So, it would be quite straightforward to implement.
>There would be a backward compatibility issue if it were implemented.

There should be no backward compatability problem if this new type were
added.  So instead of just NCAPT and NCAPTC, add NCAPTS for strings.

>I think the rational for NOT including this at the user interface level
>includes the following points:

>       For simplicity: only include (some subset of) primitive types.
>       (Symmetry would seem to ask us to handle arrays of arrays
>       of other types than char as well.)

I see no symmetry argument.  The array of strings would be the only
data type to allow variable length elements.  There is no parallel to
the length of the character string and the length of an array.  This
is truly a new data type with strong grounding in the c language. (char **argc)

>       Altho "C" has this notion of "string" type as a NULL terminated
>       array of char, there is no cooresponding fortran structure.
>       You suggest a string with "intrinsic size". This size would
>       either need be hardwired into the netcdf code (undesirable)
>       or available via the interface, further compilicating it.

Fortran has a very well defined notion of a string with a string length.
Fortran makes no assumption of how the string is terminated, but there is
a very well defined structure there just as in c.  It is particularly
displeasing that the netCDF character routines for both fortran and c
require the totally redundant strlen/len information passed to them.

In fortran, one can do this:

   character*80 line
   call foo( line(5:10) )
   ...

   subroutine foo(linei)
   character*(*) linei
   ...[at this point, len(linei) is six and we have access to the substring.

It is totally redundant to pass the number six (the string length) to
the subroutine.