[fpc-devel]Re: [fpc-pascal]Strings vs. Ansistrings

[Jonas Maebe]

>> Could you send me the program? (if it's not > 100kb zipped) Then I'll
>> check it out.
>
>I'm replying off line since there's an attachment...
>
>This program is a little bit of code to try and demonstrate what I mean.
>The syntax is test3 <filename>, where filename is any ASCII text file.
>FYI... I just threw this program together quickly, so don't expect much  :
>-)
>
>Here's what I get:
>{$H-}                    {$H+}
>go32 - works properly         go32 - garbage (or nothing)
>win32 - works properly        win32 - garbage (or nothing)

The problem is that you are using code which is really shortstring 
specific:

***
    Size := length (TestData) + 1;

    getmem (DataFromFile [CurrentLine - 1],Size);
    if DataFromFile [CurrentLine - 1] = NIL then
    begin
      writeln ('Memory error');
      halt (1);
    end;

    move (TestData,DataFromFile [CurrentLine - 1]^,Size);
***

This can never work with ansistrings. The reason is that with 
ansistrings, the compiler does all sorts of things behind the scenes. 
Read the part about ansistrings in the reference guide to see how 
ansistrings work.

The main reason the above doesn't work with ansistrings, is that 
ansistrings are actually pointers themselves, so the move command 
overwrites a lot of data. Also, they are automatically reference counted 
(the program keeeps track how many ansistring variables point to the same 
string and if no ansistring points anymore to a particular string, the 
memory the string occupied is freed or reused for another string). 
However, by using a "move()" call, you circumvent this reference counting 
(the reference counts are updated only when using normal string 
assignments etc), which means that everytime you do a readln(testdata), 
the previous value you read in is lost.

Ansistrings provide some very nice features (like the reference couting, 
automatic (de)allocation of memory etc, but for them to work you have to 
play by the rules.

>BTW; are there problems with clreol and win32 targets? I seem to be having
>a situation where the entire line is not beginning cleared. I use window ()
>to create windows, so it may be related to that. The exact same code works
>with go32 targets, so I doubt it's how I wrote it. But you never know...  :
>-)

There's probably a bug in the windows crt unit. I don't have windows 
though, so I can't check it.


Jonas