According to Frank Heckenbach:

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.

That's one reason why `StortString's should be implemented - which will have "s[0]". But this job doesn't have high priority for me ...

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).

Actually, packed arrays of chars are the same as non-packed arrays. Right now, GPC does not check whether you take the address of a packed array member, so it works with packed arrays of chars, and produces nonsense with Booleans (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?

Extended Pascal requires "packed" here.

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?).

It's not like that, but perhaps it *should* be like that ...

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). :-)

As long as GPC has no range checking at all ...

\begin{sigh} Following the tradition of a large well-known software company, I could now advertise for GPC by announcing that GPC's range checking, once it will be implemented, will be *much* better than that of Borland Pascal. Although I am sure that this will be true, I don't want to join this vaporware marketing method. \end{sigh}

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:

(It does. I thought it would not do.)

You are right. It must be renamed then.

Perhaps something like str_length or such?

"CurrentLength"?

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

Ah - the first bugs with packed arrays. I will look at them, thanks.

What about this: With (*$X+*), addresses of packed array members are only rejected if they don't lie on a byte boundary, and otherwise they work?

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

I will have a look at that, too.

Peter

Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]