On 13 Nov 2005, at 09:15, Waldek Hebisch wrote:
Frank Heckenbach wrote:
This is because GPC does not shift the range of string slices to 1..x by default, only in EP mode. Currently we don't have a separate feature options for this, so I tried with --extended-pascal now (removing the non-EP parts).
The non-EP part is called `StringExtensions', so we can switch to {$gnu-pascal}
I then get:
actual schema discriminants do not match
in this line:
valueparam(fval,ls2);Though the text of the message is somewhat misleading, the error (according to strict EP rules) is correct (i.e., the test is not EP compliant), as Length (fval) = 14 and Length (ls2) = 7:
: 6.7.3.2 Value parameters : : If the parameter form of the value parameter specification contains a : schema name that denotes the schema denoted by the required : schema identifier string, then each corresponding actual parameter contained : by the activation point of an activation shall possess a type having an : underlying type that is a string type or the char type; it shall be an error : if the values of these underlying types, associated with the values denoted : by the actual parameters, do not all have the same length.
I think that GPC is wrong here. Namely, we have:
TYPE ... s20 = string(20);
so s20 does _not_ denote the `string' schema, it is merely a type produced from that schema with a tuple.
6.7.3.2 applies only for declarations of form:
PROCEDURE valueparam(fst1, fst2: string);
That is clear if you think about intended implementation: for discriminated schema you pass just the data. For undiscriminated schema you pass the data and a descriptor. If multiple parameters have the same type you can pass a single (common) descriptor. IMHO possibility of such optimization is the only justification for 6.7.3.2. Of course, our implementation is quite different...
-- Waldek Hebisch hebisch@math.uni.wroc.pl
Frank, Waldek and others: Below I attach a note from Tony Heatherington, which was actually answering an earlier string implementation question I raised with him, but parts of which pertain to this question.
Tony: I thought you might be interested in this discussion. Ask us to 'cc' if you are interested, or join the gpc list.
Willett
Willett,
Very many apologies; your message about strings arrived while I was away, and because it clearly needed thinking about it was put on one side, and I have just retrieved it. By now it may well be too late to be useful, but let me have a go anyhow.
I think that the Standard is worded, at least in part, in a way that is intended to allow various representations of string values, and methods of parameter passing. When you say:
So, VAR parameter, capacity is same as actual parameter's capacity. Value parameter, capacity is same as length of actual parameter.
you are right, but it can be a bit more complicated. (Oh dear, it is more that ten years since I looked seriously at all this!) One question is what happens to (VAR a,b,c: string) or (a,b,c: string), and the stuff about "it shall be an error" is really concerned with such cases. Do you pass one hidden parameter or three? The Standard does not want to prejudge that decision. And does the representation of string values have a length count at the beginning or a null terminator? In either case there is a hidden parameter for each actual, but with the null terminator getting the capacity is more tedious. As you may remember, for better or worse I adopted a format for strings that puts a null at the end and also a count of unused positions (which coincides with the null when the length is the same as the capacity). It means that the capacity has to be known for some purposes which would not require it with a leading length count, for example, but allows string values to be passed in Windows API calls.
Also, because the actual corresponding to a value formal can be any string expression, the method that the implementation uses for evaluating string expressions and returning values from string functions has to be stirred in as well. And yet again, the domain type of a pointer can also be a schema, for example "string", and it can help to deal with these in a related way. Do you have one-byte or two-byte characters, or both?
Probably by now you have worked all this out, and again I apologise for not responding more promptly. If it would help to expand any more, do let me know.
... All the best,
Tony
--
Prospero Development Software London SW18 1PY Tel: +44 20 8875 9011