[fpc-pascal] TStringStream.DataString returns garbage?

[Giuliano Colla]

Lars ha scritto:
> It's actually a common mistake. Also @s vs "s", and @s[1], it can be
> confusing.
>
> It's one thing I don't like about unsafe languages, pointers, and such
> stuff. It's as if we are programming in advanced C, or C++. Common,
> pointer mistakes? this is C? Really? Can't we make it safer? LOL.
>
> What could be done to make this safer? I don't know. What does java do in
> a situation like this? Could we learn from it?
The only "clean" solution I'm aware of is is the one used in old times 
by PLM, which completely banned the "implicit pointer" born with C language.

If you just have a local string (or data structure), the name must be 
"qualified". If /s/ is a string you must either use /@s/ to indicate the 
pointer to the string or /s[n]/ to indicate an element of the string. If 
/b/ is a structure, /b.something/ is valid and/@b/ is valid, but the 
usage of /s/ or /b/ alone is not allowed.

Whenever you're not dealing with local, static data, then you have the 
"based" construct, which allows to reserve storage for a pointer, and 
describes what the pointer points to, providing both strong type 
checking, and an easy way to dereference when required. Again any 
ambiguity is impossible.

An example of the PLM syntax is:

Declare p pointer;
Declare s based p (256) Byte;
     and also, if required,
Declare w based p(128) Word;

I've implemented an extension of FPC to support the "based" construct, 
which I find very useful, to get rid of the c-style p^something, and to 
make the code more readable and easier to maintain.
However I've never submitted my personal patch, because when I proposed 
it, it didn't rise any interest, and I'm always two steps behind with 
FPC versions....