Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!versatc!leadsv!laic!darin
From: darin@laic.UUCP (Darin Johnson)
Newsgroups: comp.lang.c
Subject: Re: strings
Message-ID: <558@laic.UUCP>
Date: 18 May 89 03:08:06 GMT
References: <10250@socslgw.csl.sony.JUNET> <8466@chinet.chi.il.us>
Reply-To: darin@laic.UUCP (Darin Johnson)
Organization: Lockheed AI Center, Menlo Park
Lines: 42

>>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@pyramid.pyramid.com)
	We now return you to your regularly scheduled program.