strings

[Darin Johnson]

>>Yes.  You throw away the C library (which I understand is part of the
>>proposed ANSI standard) and the language's definition of how strings
>>are represented, you define your own representation of strings, and
>>you implement your own library.
>
>Why throw anything away?  You can store the lengths elsewhere and
>still use the null-terminated representation that the library
>routines want to see.
> struct eg { unsigned int str_len;
>             char *the_str;
>            };

This is (almost) exactly what I do in VMS.  I prefer using null
terminated strings, because this is what I am used to, and what the
library routines expect.  However, VMS functions that deal with strings
need a string descriptor (which works fine in stuff like pascal, because
the string type is built in).  It includes a pointer, a string length,
a type (lots of different kinds of descriptors), and something else
that I forget.

A C header defines a macro $DESCRIPTOR to statically create these
descriptors.  For constant strings, you just do
$DESCRIPTOR(strd, "constant");  For dynamic strings, I do:

  char str[512];
  $descriptor(strd, str);

Then I can use str as normal.  When I need to pass this to/from a
routine, I adjust the string count, or append the null (which is easy,
since the count is returned in a lot of calls).  It is a bit harder for
automatic variables, allocated strings, etc.  I wrote a simple library
for this purpose once, but it never really caught on for me.  VMS has
some nice string manipulation routines but I never use these either, since
I prefer to use the C library routines (the VMS routines can append a
string, allocating new memory if necessary, etc.).

So it's not so bad using both formats at once, with only a minimal
overhead needed to convert when you need to.

-- 
Darin Johnson (leadsv!laic!darin at pyramid.pyramid.com)
	We now return you to your regularly scheduled program.