On 17 Sep 2005, at 04:31, Maurice Lombardi wrote:
Frank Heckenbach a écrit:
Pascal Viandier wrote:
I have to say, I understand your explanation but not the fundamental meaning of it. By inspecting the local variable with gdb, I see you are right. But since I declared the global string variable as a String(40), I expected the capacity passed to the procedure to be 40, not 3, which is the actual length, not the total string capacity . However, I think this is a rather strange behaviour. Why the original string capacity is not passed along with the value? In fact, this means the local string is not the same type as the one I declared globally and passed by value. Am I wrong?
That's right -- and that's a general property of value parameters. E.g., if you declare an integer subrange variable and pass it to an integer parameter (or vice versa), or an integer variable to a real parameter, or a char to a string parameter, the actual parameter will not have the same type as the formal parameter. Indeed, in this case it's more surprising, but actually, the alternative would be surprising in even more subtle ways. Then, e.g., these two calls could produce different results: var a: String (10); procedure p (s: String); begin ... end; begin a := 'foo'; p (a); p ('foo'); end. This would clearly violate the properties of value parameters.
You are right. Still I would consider as "more natural" the rule: with a value String parameter (without explicit capacity),
- copy the original string with its capacity if it has one: p(a)
- supply capacity = length if not : p('foo')
"more natural" means that I would be able to understand directly the surprising behaviour observed originally by Pascal, without having to ask to somebody who knows so well the internals of gpc.
Maurice
-- Maurice Lombardi
In such cases our intuitions may differ. This is why we have standards.
Tony Heatherington's brief description of the Extended Pascal standard follows. Tony was on the EP committee, and he has implemented a very high-quality EP compiler. (from: http://www.prosperosoftware.com/EPIntro.html#7)
----------- Heatherington -------------------------------- 7. Strings In classic Pascal, the only string facilities are associated with packed arrays of char. This is another area in which a variety of local extensions have arisen. Extended Pascal includes provision for dynamic string types, and unifies them with classic Pascal strings and with characters.
String variables are declared with a maximum capacity, for instance:
VAR s1,s2: string(20); fname: PACKED ARRAY [1..20] OF char; String values have a length (number of characters). A dynamic string variable such as s1 can hold a value of any length from zero up to its capacity, and the object code keeps track of the current length. With a fixed string such as fname, as found in classic Pascal, the length of the contents is equal to the capacity; when a shorter value is assigned to fname, it is padded on the right with spaces until it fits. A variable of type char has a capacity of 1. Variables of these three kinds, together with string literals and character constants, produce general string values. In addition, individual characters or substrings of string variables can be referenced by indexing, for instance s1[i] or fname[1..8].
String values can be concatenated using the + operator, and constants can be defined by constant expressions of string type, eg. 'ABC'+chr (13). There are predeclared functions for the commonly-required string operations such as locating a substring within a longer string.
Strings can be written to or read from textfiles, and versions of the textfile read and write procedures are provided which take a string variable in place of the file, making all the conversion and editing processes available internally.
A string may be declared with capacity fixed at compile time, as in the example above, or defined by a run-time variable expression. There are also provisions for formal parameters which adjust themselves to the actual parameter at each call.
PROCEDURE p (VAR s: string) Dynamic strings of different capacities may be passed to this procedure with each call; the code within the procedure can discover the capacity of each actual parameter by reference to s.capacity.
If a variable n has the value 10, a string declared as string(n) has the same type as one declared as string(10) for compatibility purposes (though the type checking cannot be performed until run- time). As will be seen in the next section, this rule and the adaptable formal parameters are both particular cases of facilities that apply to all schematic types, and arise from string being formally defined to be a predeclared "schema" with additional special properties.
--------------------------------------------
The Extended Pascal Standard itself, unfortunately, is very hard to read in this regard because to understand parameter passing of "string" you have to understand a lot of terminology that exists elsehere in the document. The section on value parameter passing is 6.7.3.2. I'll attach an image of the main part of that section (sorry my PDF is an image file; anyone who has a character-based PDF, please send me it!) It says that the formal parameter, when the procedure is activated, has the same TYPE as the actual parameter. I believe this would mean that, as Tony says far more briefly, for a variable as actual parameter, the formal parameter takes on the capacity rather than the length.
-----------------------
Upshot: Maurice's intuition appears to match the Extended Pascal Standard (at least for variables), and is the same as Tony Heatherington's reading of the Standard.
However, Pascal Vandever's original case was passing a constant string, in which case I believe (not totally sure) the length=capacity, so gpc works consistently with EP already i n that case.
- Willett Kempton
------------------ Extended Pascal standard (attached as image (sorry) ) ----------------------------
