[Coco] Strings in DECB

[William Astle]

On 2015-10-20 20:01, Theodore (Alex) Evans wrote:
> I was talking with a friend.  We had a disagreement about the maximum length of strings under DECB. He claimed it was 128 and I believe d it was 255. So I did some testing. The results were puzzling. I created a string and began extending it. Any attempt to extend a string of 100 characters or more (even with an empty string "") results in an OS error as does any attempt to extend a string past 100 characters, but I can define and use a string up to 255 characters in length.

I'm writing this in case others are curious about the details. All of 
this information can be verified by studying the Unravelled series.

As others have noted, the actual maximum length of a string is 255 
bytes. If that is exceeded, you get an LS error. The OS error means you 
are out of string space, which is a different issue altogether.

Color Basic reserves 200 bytes of string space by default. You would 
think that would be enough to build a 200 byte string. However, there 
the way concatenation works is as follows:

1. The total length of the new string is calculated. If it's greater 
than 255, you get an LS error.
2. String space for the entire length of the new string is allocated. If 
there isn't enough, that gives an OS error.
3. The two strings are copied into the newly allocated string space.

After that point, what happens to the result depends on context. If 
you're doing something like A$ = A$ + "A" then the new string is 
assigned to A$. The space used for the original A$ becomes available for 
future use.

What that means is that a loop extending A$ a byte at a time will never 
be able to extend the string past half the size of the available string 
space. You'll need at least 510 bytes of string space to make that work 
a maximum length string. To be safe for your testing, 1000 is probably 
nicer.

There are some other wrinkles with how string space is used:

- A constant string that has not been altered in any way will use no 
string space. Instead, the string constant in the program will be 
referenced instead of copying the string to string space
- Concatenating with a NULL string counts as modifying a string and will 
cause a constant string to be copied into string space
- A "fielded" string (Disk Basic) will occupy space in the Disk Basic 
file buffers instead of string space.
- A NULL string (0 length) occupies no string space regardless. It 
doesn't need any.
- string space is not actually freed until a new allocation fails. At 
that time, the entire set of active strings is scanned and the data 
compacted to consolidate any free space into one lump and only then does 
the allocation fail if there isn't enough space. This is the garbage 
collection process and it can cause some substantial slowdowns when 
string space is tight. That's why it's often good to have a much larger 
string space than strictly needed for programs that do a lot of string 
manipulation.

I suspect the idea that the maximum length of a string is 128 comes from 
the fact that DSKI$ and DSKO$ operate on a pair of strings that are 128 
bytes long. However, the reason for that is due to the sector being 256 
bytes long which is one byte longer than the maximum string length.