Jesper Lund wrote:
MY MISTAKE! Read[ln] work correctly and never exceeds the string capacity, and my problems are totally UNrelated to the missing range checks in some string expressions that I mentioned in the original post.
I'm calmed! :-)
ADVICE TO GPC USERS:
If you add #0 to a string (in order to call functions in the C library), it is a *very* good idea to use strings whose capacity (max length) are not divisible by 4. In that case, at least one byte is "wasted" to achieve 4-byte alignment, and adding #0 should not overwrite other variables.
I'm not sure if it's a good idea to rely on such internal things. The alignment could be different from 4 on some systems.
However, we have already discussed automatically making the array bigger than the capacity by 1 for exactly this reason. I hope it's not much work, Peter, so perhaps you can do this change until the next version (whereas the automatic String-CString conversions will follow later).
ADVICE TO GPC USERS:
If you add #0 to a string (in order to call functions in the C library),
it
is a *very* good idea to use strings whose capacity (max length) are not divisible by 4. In that case, at least one byte is "wasted" to achieve 4-byte alignment, and adding #0 should not overwrite other variables.
I'm not sure if it's a good idea to rely on such internal things. The alignment could be different from 4 on some systems.
You're right, Frank. I shouldn't have used the word `advice' as it may not work on all platforms supported by GPC, and in any case it's bad programming practice to rely on internal features when writing programs!
However, we have already discussed automatically making the array bigger
than
the capacity by 1 for exactly this reason. I hope it's not much work, Peter, so perhaps you can do this change until the next version (whereas the automatic String-CString conversions will follow later).
This sounds like a very good idea to me!
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?
I'm not really that familiar with the GPC internals, so if this is a stupid suggestion, please just ignore it!
Jesper Lund
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. But you will probably have to draw a line somewhere: supporting any undocumented feature in BP must be an implementation nightmare ...
-
Frank Heckenbach -
Jesper Lund