Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2002-02

Incorrect RT 216 error?

10 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Unknown author

I'm getting an RT 216 error in a spot that seems it shouldn't be occurring, but it may just be me...

I'm using FPC 1.1 dated 2001/06/19. The target is Win32, running on Windows 2000 Professional. I've included a small sample, so you can see what I'm referring to.

The error occurs when I attempt to add a character to a string. Basically, I'm rewriting a program that uses readln to get data from a file. Some of the files are quite large, so I'd rather use blockread (which is faster). I read a block from the file, then scan the block starting from the first position. As the block is being scanned any character other then #10 and #13 (RETURN and LINEFEED) are ignored, while the rest are appended to a string variable. But I get the RT 216 on line 82 (according to -gl) when I try something like this:

string [string_index] := block [block_index];

If I use concat instead it works, but it's *much* slower:

string := concat (string, block [block_index]);

Now, in order to make certain that the string is empty before each iteration I use string := '' (an empty string, which is on line 73 of the attached file). Interestingly, if I change that line to string := ' ' (that's a single space between the quotes) I no longer get a 216 error, but all the strings display on the screen are just a single, seemingly random, character. Sigh...

This seems like an FPC bug, but knowing me it's something I'm doing wrong. Maybe trying to "clear" a string using string := '' is wrong, but I don't recall that being a problem before.

Anyway, TIA for any help you can give me.

Jim

Reply by email

Peter Vreman
Show quoted text 6 lines
I'm getting an RT 216 error in a spot that seems it shouldn't be occurring, but it may just be me... I'm using FPC 1.1 dated 2001/06/19. The target is Win32, running on Windows 2000 Professional. I've included a small sample, so you can see what I'm referring to.

Can you try it using the latest 1.0.5 or 1.1 snapshots.

Reply by email

Unknown author
Can you try it using the latest 1.0.5 or 1.1 snapshots.

I just got a snapshot -- Version 1.1 [2002/02/15] -- and the same thing happens.

BTW; are there problems with the mirrors? I had a heck of a time getting the .zip files. Austria would have a file that USA didn't, some of the ones I did get were 0 bytes while others were 3 times the size they should have been, so they wouldn't unzip properly. It was tough. Right now I'm at work, which has a high-speed internet connection (and I'm the only one in the office right now) so I don't think it's anything here. Anyone else having problems?

Jim

Reply by email

Jonas Maebe
to Unknown author: I'm getting an RT 216 error in a spot that seems it shouldn't be occurring, but it may…
string variable. But I get the RT 216 on line 82 (according to -gl) when I try something like this: string [string_index] := block [block_index];

Your problem is that

a) you are using ansistrings
b) you are trying to use them the same way as shortstrings

a and b don't mix very well as you have found out. Ansistrings are dynamically allocated on the heap and dynamically grow and shrink (though automatically inserted calls to helper routines by the compiler) when they are modified.

You first set the string to '', which, when the string is an ansistring, simply releases all memory allocated for it and then stores nil in it (an ansistring is a pointer to a record containing the current length, max length, number of references and the actual string stored as an array of char terminated by a #0). Next, you start putting data in it, which obviously causes a crash since the string is nil.

Now, how should you do it then? One way is:

If I use concat instead it works, but it's *much* slower: string := concat (string, block [block_index]);

In this case, the concat helper makes sure enough memory gets allocated for the anistring before anything is inserted. Of course, doing this for every character makes it very slow as you have found out.

Another way is to use the setlength() procedure, with which you can create an empty ansistring with enough room for a specified amount of characters. Please read the manual for more information about ansistrings.

Jonas

Reply by email

Ingmar Tulva
to Jonas Maebe

On Fri, 15 Feb 2002, Jonas Maebe wrote:

}Now, how should you do it then? One way is:
}
}> If I use concat instead it works, but it's *much* slower: }>
}> string := concat (string, block [block_index]); }
}In this case, the concat helper makes sure enough memory gets allocated }for the anistring before anything is inserted. Of course, doing this for }every character makes it very slow as you have found out. }
}Another way is to use the setlength() procedure, with which you can create }an empty ansistring with enough room for a specified amount of characters. }Please read the manual for more information about ansistrings.

As I recall, ansistrings start with index 0, not 1 (like shortstrings do). Then this is to be corrected, too. Not sure, though, I always start my files with {$H-}.

--------
Ingmar Tulva

Reply by email

Jonas Maebe
to Ingmar Tulva
Ingmar Tulva wrote
As I recall, ansistrings start with index 0, not 1 (like shortstrings do). Then this is to be corrected, too. Not sure, though, I always start

That not correct, they do start at index 1. Only pchar's start at index 0.

Jonas

Reply by email

Ingmar Tulva
to Jonas Maebe

On Sat, 16 Feb 2002, Jonas Maebe wrote:

}> As I recall, ansistrings start with index 0, not 1 (like shortstrings }> do). Then this is to be corrected, too. Not sure, though, I always start }
}That not correct, they do start at index 1. Only pchar's start at index 0.

Wow, that's surprise. It means, when one does:

  VAR s:Ansistring;
  s[2]:=someting;

the compiler actually produces code which puts 'something' at address [s+1]? E.g.

mov EDI,[s]
mov AL,[something]
mov [EDI+1],AL

or similar? Otherwise typecast to PChar wouldn't work.

------

Ingmar

Reply by email

Unknown author
Another way is to use the setlength() procedure, with which you can create an empty ansistring with enough room for a specified amount of characters.

This did the trick nicely. Thanks.

Jim

Reply by email

gj bart
to Unknown author

I guess it doesn't get any more fundamental than this, but... When I open the folder dosw32104full and further go into folders demo and text, and finally click some pascal source files (hello.pp, qsort.pp) I'm sent into the dev-pas ide. Since dev-pas is no longer supported, I guess I'd like to use freepascal stuff exclusively. Obviously I'm confused about something (more like several things) so can somebody shed some light on what's going on? Thanks.

gj

Reply by email

Adam Naumowicz
to gj bart

Hello,

gj bart wrote 7 lines
I guess it doesn't get any more fundamental than this, but... When I open the folder dosw32104full and further go into folders demo and text, and finally click some pascal source files (hello.pp, qsort.pp) I'm sent into the dev-pas ide. Since dev-pas is no longer supported, I guess I'd like to use freepascal stuff exclusively. Obviously I'm confused about something (more like several things) so can somebody shed some light on what's going on? Thanks.

It just shows that you have that ide associated with *.pp files in your Windoze registry. If you want to change this behaviour just go to something like:
'Settings->Folder Options->File Types' (I'm not 100% sure since I don't have a Win32 machine at hand) and tell Windows to open Pascal files with another editor of your choice.
Hope this will help,
Adam Naumowicz

--------------------------------------
WWW: http://math.uwb.edu.pl/~adamn/
--------------------------------------

Reply by email