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... ;-)