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 parameterform of the valueparameterspecification contains a : schemaname that denotes the schema denoted by the required : schemaidentifier string, then each corresponding actualparameter contained : by the activationpoint of an activation shall possess a type having an : underlyingtype that is a stringtype or the chartype; it shall be an error : if the values of these underlyingtypes, associated with the values denoted : by the actualparameters, 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...