Frank Heckenbach wrote:
Pascal Viandier wrote:
I am porting SUN Pascal code to GNU Pascal. When I first read the GNU Pascal documentation (the pdf manual), I was pleased to see that GNU Pascal strings were in fact records with the length and the string text: this map perfectly with SUN Pascal VARYING[..] OF CHAR we use, since it is a record with 4 bytes for the length and an array of char. So, no porting problem...
Then we need to correct the documentation. Where exactly does it say so? (The manual is long.)
I presume what Pascal Viandier is referring to is in section 6.2.11.5 EP's Schema Types including String http://www.gnu-pascal.de/gpc/Schema-Types.html#Schema-Types. Toward the end of the section there is this description of the GPC String schema type implementation:
"An important schema is the predefined String schema (according to Extended Pascal). It has one predefined discriminant identifier Capacity. GPC implements the String schema as follows:
type String (Capacity: Cardinal) = record Length: 0 .. Capacity; Chars: packed array [1 .. Capacity + 1] of Char end;
The Capacity field may be directly referenced by the user, the Length field is referenced by a predefined string function Length (Str) and contains the current string length. Chars contains the chars in the string. The Chars and Length fields cannot be directly referenced by a user program. "
The type declaration of the implementation's data layout is somewhat misleading in that it doesn't explicitly show that the storage for the Capacity discriminant identifier is actually implemented as a "hidden" record field of the string storage layout.
Perhaps a better way to describe the implementation layout details is:
"... GPC implements the required String schema data type, String(Capacity), as a record in memory with the following data fields:
Capacity: Cardinal; Length: 0 .. Capacity; Chars: packed array [1 .. Capacity + 1] of Char
..."
However, I question the wisdom of embedding the implementation details of storage layouts in a general type description of language type capabilities since it complicates maintaining accurate user documentation with "subject to change" implementation details being scattered throughout the documentation. A better approach I've seen in some Pascal compiler manuals is to have all the internal storage implememtation details for the data types in a separate section of the manual. It is better for users since all the data type internal memory layout details can be found in one place when one needs to know that information for interfacing with other languages and/or compiler implementations. And it is better for documentation maintainers since there is only one place in the documentation which needs to be revised when the compiler's internal implementation details for data types change. (For GPC, it would be preferrable to have such internal data types implementation details autogenerated as much as practical from the compiler sources since that would be the best way to maintain accurate documentation without requiring a lot of additional manual effort for documentation.)
Gale Paeper gpaeper@empirenet.com