Problems with strings in GPC beta 971001

[Frank Heckenbach]

Jesper Lund wrote:

> Regarding the discussion of GPCs 3-4 different string types and the *planned*
> generic string (AnyString):
> 
>   Could you use the Extended Pascal string (augmented with the extra byte to
> hold the #0 char) as the generic string (AnyString), and let the compiler add
> the necessary conversion code (Borland <-> EP string; Cstring <-> EP string;
> array of char <-> EP string) whenever the program calls a built-in function
> with a different string type than EP string?

For value parameters, this seems the best solution, indeed. For constant
parameters, things are even easier, because a capacity is not needed, so we
only have to pass the address of the first character and the current
(constant) length.

However, what's problematic is var parameters. Since the procedure must be
able to change their length, and that's done differently for each of the four
string types (EP: setting an integer; BP: setting a byte; SP: filling with
spaces; CString: setting a #0 terminator)-:, the procedure has to know the
actual string type.

According to my suggestion of AnyStrings, a procedure with a var AnyString
parameter could do the following operations on it, which will do the right
thing for the actual string type transparently to the programmer:

- Length
- AssignLength
- Capacity
- Assignment to/from other strings of any type. (This includes passing as
  value or const parameters.)
- Passing as var parameters of AnyString (not "any string"! ;-) type
- Accessing single characters with "[n]" -- where I'm not sure if the index
  should always start at 1, or as in the original string/array. The former
  would be easier to handle; for the latter, the starting index would have to
  be passed (internally), too.

Of course, when we have AnyString, it's quite easy to convert all string
parameters in the RTS functions to AnyString, so those functions will work
on all string types.

> P.S.  Peter and Frank; you *have* convinced me that there is a need for the
> Borland string type.  When I wrote the message yesterday, I didn't realize
> that there were so many undocumented BP features, nor the extent to which
> people used them to work around limitations and inefficiencies in Borland
> Pascal.

Honestly, I wasn't aware of the extent until I came to GPC, though I'd been
using the things in BP for years...

> But you will probably have to draw a line somewhere: supporting any
> undocumented feature in BP must be an implementation nightmare ...

We've decided, *not* to produce a warning in "--borland-pascal" mode when
the data exceed 64 KB... ;-)

-- 
Frank Heckenbach, Erlangen, Germany
heckenb at mi.uni-erlangen.de
http://home.pages.de/~fjf/links.htm