The African Chief wrote:

...

...

It would not be too difficult to make "MyStr.length" and "MyStr.String" accessible "record fields" of strings. Would it be desireable?

Yes! (At least length; the String part is accessible anyway with s[n].)

...

I am not sure how this fits into the standard ...

I'm not, either. If it conflicts, it should be disabled with "--extended-pascal", I suppose.

It should be disabled, with "-borlland-pascal" as well.

But how would you translate references to s[0] in BP then? I know, there shouldn't be any in most programs, but sometimes it can be useful, e.g. for efficiency. But it's ok for me if it's only enabled with {$X+}, see below.

Peter Gerwinski wrote:

2. In GPC strings, the schema discriminant "Capacity" is accessible as a "record field" of the string. Is this okay by ISO 10206, and should it be done for other schemata this way, too? And how to tread the "length" field of a string? ISO 10206 6.4.3.3 does not say anything about that. I could imagine the string schema type to be something similar to

   Type
     String ( Capacity: Integer ) = record
       length: Integer;
       String: packed array [ 1..Capacity ] of Char;
     end (* String *);
   
   

   except that the "String" field is automatically dereferenced.

Oh - I thought a string was like this already. (My previous mails were based on this assumption.) I think I read this somewhere, but don't remember where.

But, a *packed* array? If I remember correctly, it's not possible to get an address of a component of a packed record/array (because they could possibly not start on a byte boundary) (but when trying it, I encountered some problems, see below).

If this is so (and won't be changed so that it is possible to get an address of those components that actually start on a byte boundary), I'd vote for an un-packed array here. BTW: Is there any advantage in packing here? AFAICS (at least with Linux), an un-packed array of char is exactly as big as a packed one. Is this not always so?

It's "1..Capacity + 1". (Increasing the index by one adds one char.)

...

+1 to allow for a trailing zero (or zero's in case of Unicode...).

Does this mean strings will always have an additional trailing #0? Do the string routines currently support this (i.e. automatically add a #0 at the end; but they should not recognize #0 as a terminator, but only rely on the length field)? That would be good, because it simplifies converting a string into a CString a lot (just "CString(@s[1])", right?).

What about the following:

• Default mode (and Extended Pascal mode): The length field cannot be accessed (except with "length ( MyStr )".)

• With extended syntax (*$X+*): The length field can be read- and write-accessed.

Okay like that? Or perhaps better to have it in default mode, too, and to switch it OFF in Extended Pascal mode? I think it's best as above because you should assign a new length to a string only if you know exactly what you are doing.

Sounds good! {$X} is a local switch, isn't it (so one can turn it on and off around code that needs it, and be safe from accidents elsewhere). It would be even better than BP (where accidental writes to s[0] are not even detected by range checking). :-)

BTW: Should the field be called "length" like the function length? It might give conflicts with "with" statements ("with" works with schemata, doesn't it?) as in:

with dest_str do begin length:=length(src_str); ... end;

Perhaps something like str_length or such?

(* By the way: Good news for all friends of schemata! They might be finished (except, of course, bugs) this week ... *)

What? The bugs will not be finished? What an omission! ;-)

As I said above, I had some problems with the new packed arrays. I tried the following:

program t; var q:packed array [1..10] of boolean; y:^boolean; begin y:=@q[3] end.

and it compiled (though I think it shouldn't), giving quite a strange result in y.

Then I did:

program t; var q:packed array [1..10] of boolean; y:^boolean; i:integer; begin for i:=1 to 10 do y:=@q[i] end.

gpc said "invalid lvalue in unary &".

Though this shoudln't compile, this error message seems strange to me. I'd have expected "Attempt to take address of bit-field structure member", as with packed records.

Next I tried:

program t; var q:packed array [1..10] of boolean; y:^boolean; i:integer; begin for i:=1 to 10 do y:=@(q[i]) end.

The result was: "parse error before '('" and some more error messages. (The same with an un-packed array here.)

Should the "()" be allowed here (though not required)? FWIW, TP5.5 doesn't allow them, BP7.0 does...