Re: NUL to terminate strings; was reinventing ASCII?

Richard Bos wrote:
> Eric Sosman <Eric.Sosman@[EMAIL PROTECTED]
> wrote:
> 
>>      Pemberton's proposal (as I understood it, anyhow) was to
>> store a string's length just before its first character, in
>> much the say some malloc() implementations store metadata
>> just before an allocated block:
>>
>> 	[12] V o g o n   p o e t r y
>> 	     ^
>> 	     The decayed `string' points here
>>
>> strlen() would swizzle its argument to locate and fetch the 12
>> without hunting for a (non-existent) sentinel character.  And
>> my point was that
>>
>> 	[12] V o g o n   p o e t r y
>> 	                 ^
>> 	                 `string+6' points here
>>
>> ... would cause strlen() to mis-swizzle its argument and
>> pick up some kind of garbage length.
> 
> Not necessarily. It would require pointers (to char and void, at least)
> to consist of a base pointer and an offset, and strlen() to get its
> length from the base pointer, not from base+offset. This would be
> needlessly cumbersome on most systems, but not impossible.

     It was not my impression that Pemberton was proposing
"fat pointers."  Even if he were, there would be problems
(perhaps not insuperable, but problems nonetheless) me****ng
such a scheme with C's view of the world:

	char buff[100];
	strcpy(buff, "Vogon poetry");
	strcpy(buff+strlen(buff), "Slartibartfast");

 From C's point of view these are two independent strings (I'm
assuming the length governs a string's extent and that no
sentinel character is used).  Where are the two lengths (or
information to compute them) stored?

     (Is this an "artificial" construct?  When handling large
numbers of short-ish strings, I have more than once tried to
minimize malloc() overhead by allocating a big pool and cramming
multiple strings into it, cheek by jowl, until the pool fills and
I allocate a new one.  The idea of storing many strings back to
back in one big char[] is not so far-fetched.)

-- 
Eric Sosman
esosman@[EMAIL PROTECTED]