Modifying string length?_(re)

Thu, 1 May 1997 13:00:56 +0200 (MET DST)

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]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)