Re: [fpc-pascal] Porter Stemming for FPC 2.0
memsom <[EMAIL PROTECTED]> wrote:
> Reading PChars at negative indexes? Buffer underrun in other
> words... This
> is absolutely not a good thing. If FPC is preventing buffer under
> and
> overrruns, then it is actually right, for once, and Delphi is
> wrong,
> wrong, wrong!
Yeah, it seems dumb. Well, I'm more a Turbo Pascal than a Delphi
programmer and not a software professional. I don't actually know
what a pchar is... I guess it's a pointer to a strong that was added
to Delphi to talk to the Windows API?
Anway, if you look at this guy's code, I'm convinced that he falls
into the "power user" category. He has no problem writing ASM but he
also provides a a "pure Pascal" solution (chosen at compile-time).
And he's apparently benchmarked his code and is agressively trying to
optimize it.
And it's not a buffer under-run per se. He's checking the ends of
words against a series of word endings. He calculates a negative
index when he checks a long ending like '-ization' against a short
word like 'word' ... he calculates that he has to start checking
character -3 of 'word' [length('word'-length('ization')] ... The
outcome of this checking is "true, the word ends in the ending" or
"false" and of course 99% of the time it's false. I think it's
impossible that he could get a wrong result because even if the
garbage at memory p[-3] to p[-1] matches the word ending, the word
itself will not.
So, I mention all this because it is an obscure point of
incompatibility between FPC 2.0 and Delphi 5-7 (and FPC 1.x) ... In
my case, this code worked fine and then it broke... just turning off
range-checking isn't an answer for me, as I need $R+ to catch my own
errors. Luckily, it was easy enough to wrap IF statements around
these bits.
> A question... how do you know the memory at the negative index is
> valid?
I've explained why garbage won't goose the algorithm. As to why it
does not GPF, I suppose this pchar is always pointed into the
"middle" of the data segment and the negative indices are always
single digits. In the zip file containing my fix, I included the
test program that drives this guy's unit and the test data. It
compiles and runs fine in Delphi 7 (you may have to comment out the
"{$mode DELPHI}") on the test data.
-Alan
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Turbo Pascal/legacy data file issue.
Has anyone come up with a set of routines for converting between Turbo
Pascal's 6-byte "real" format and FPC's real number format?
I am trying to use FPC to update a legacy TP 5.5 program. I've got most of
the "major" issues solved and am now finding that I'm having trouble
reading legacy data files. Many of these data file are "file of XXXRec"
where "XXXRec" is a rather large and complex Record containing strings,
integers, bytes, enumerated types, and reals.
My problem is that I am going to need to be able to read these existing
files (without modification) into the new version of the program.
I've been able to use the "{$PACKRECORDS 1}" and "{$PACKENUMS 1}"
directives to take care of everything else. But now I realize that Turbo
Pascal used a 6-byte real representation while FPC uses either a 4 or 8-bit
representation.
It appears that I'm going to need to make some kind of a special type,
perhaps a packed record with a "byte", a "smallint" and a 4-byte
"longword". Then, I read this value from the existing file and convert it
into a "real". Then, when I want to write the file (or another file) I
convert back to this record type when I fill the record I'm going to write.
Here's a simple program to demonstrate the issue. In Turbo Pascal 5.5
(Downloaded from http://bdn.borland.com/article/0,1410,20803,00.html) this
code generates a 12-byte file. FPC generates a 16-byte file. (Actually,
the preprocessor directives shown appear to have no effect on this
code--not complaining since the docs don't make it appear that it should,
just pointing it out.)
Program testrec;
{$IFDEF FPC}
{$MODE TP}
{$PACKRECORDS 1}
{$ENDIF}
type
realrec = record
t1 : real;
t2 : real;
end;
var
realfile : file of realrec;
r : realrec;
begin
r.t1 := 1.0;
r.t2 := 2.0;
assign ( realfile, 'c:\r.rfl' );
rewrite ( realfile );
write ( realfile, r );
close ( realfile );
end.
Any ideas appreciated!
Thanks,
Lowell C. Savage
[EMAIL PROTECTED]
505-667-6964 (office/msg)
360-961-8965 (cell/msg)
505-667-4341 (shared fax)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Turbo Pascal/legacy data file issue.
Lowell C. Savage wrote:
> Has anyone come up with a set of routines for converting between Turbo
> Pascal's 6-byte "real" format and FPC's real number format?
http://www.freepascal.org/docs-html/rtl/system/real2double.html
>
> I am trying to use FPC to update a legacy TP 5.5 program. I've got most
> of the "major" issues solved and am now finding that I'm having trouble
> reading legacy data files. Many of these data file are "file of XXXRec"
> where "XXXRec" is a rather large and complex Record containing strings,
> integers, bytes, enumerated types, and reals.
>
> My problem is that I am going to need to be able to read these existing
> files (without modification) into the new version of the program.
>
> I've been able to use the "{$PACKRECORDS 1}" and "{$PACKENUMS 1}"
> directives to take care of everything else. But now I realize that
> Turbo Pascal used a 6-byte real representation while FPC uses either a 4
> or 8-bit representation.
>
> It appears that I'm going to need to make some kind of a special type,
> perhaps a packed record with a "byte", a "smallint" and a 4-byte
> "longword". Then, I read this value from the existing file and convert
> it into a "real". Then, when I want to write the file (or another file)
> I convert back to this record type when I fill the record I'm going to
> write.
>
> Here's a simple program to demonstrate the issue. In Turbo Pascal 5.5
> (Downloaded from http://bdn.borland.com/article/0,1410,20803,00.html)
> this code generates a 12-byte file. FPC generates a 16-byte file.
> (Actually, the preprocessor directives shown appear to have no effect on
What effect should it have?
> this code--not complaining since the docs don't make it appear that it
> should, just pointing it out.)
The 6 byte real isn't supported by fpc because it isn't handled by the
fpu and thus deadly slow. For maybe 12 years, every new PC has an fpu.
>
> Program testrec;
> {$IFDEF FPC}
> {$MODE TP}
> {$PACKRECORDS 1}
> {$ENDIF}
> type
> realrec = record
> t1 : real;
> t2 : real;
> end;
>
> var
>realfile : file of realrec;
>r : realrec;
> begin
>r.t1 := 1.0;
>r.t2 := 2.0;
>assign ( realfile, 'c:\r.rfl' );
>rewrite ( realfile );
>write ( realfile, r );
>close ( realfile );
> end.
>
> Any ideas appreciated!
>
> Thanks,
>
>
> Lowell C. Savage
> [EMAIL PROTECTED]
> 505-667-6964 (office/msg)
> 360-961-8965 (cell/msg)
> 505-667-4341 (shared fax)
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porter Stemming for FPC 2.0
On 19 Sep 2005, at 17:40, Alan Mead wrote: I think it's impossible that he could get a wrong result because even if the garbage at memory p[-3] to p[-1] matches the word ending, the word itself will not. There's not necessarily garbage at those locations, those addresses may simply not be mapped (i.e. cause an access violation/general protection fault when accessed). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Turbo Pascal/legacy data file issue.
Well, I found a "Real2Double" function in the System unit that converts
from an old TP 6-byte "real" to an 8-byte double. (Guess I should have
looked a little harder, there.) But I'm not seeing anything going the
other way. Anyone?
Thanks,
Lowell
At 12:56 PM 9-19-05, Lowell C. Savage wrote:
Has anyone come up with a set of routines for converting between Turbo
Pascal's 6-byte "real" format and FPC's real number format?
I am trying to use FPC to update a legacy TP 5.5 program. I've got most
of the "major" issues solved and am now finding that I'm having trouble
reading legacy data files. Many of these data file are "file of XXXRec"
where "XXXRec" is a rather large and complex Record containing strings,
integers, bytes, enumerated types, and reals.
My problem is that I am going to need to be able to read these existing
files (without modification) into the new version of the program.
I've been able to use the "{$PACKRECORDS 1}" and "{$PACKENUMS 1}"
directives to take care of everything else. But now I realize that Turbo
Pascal used a 6-byte real representation while FPC uses either a 4 or
8-bit representation.
It appears that I'm going to need to make some kind of a special type,
perhaps a packed record with a "byte", a "smallint" and a 4-byte
"longword". Then, I read this value from the existing file and convert it
into a "real". Then, when I want to write the file (or another file) I
convert back to this record type when I fill the record I'm going to write.
Here's a simple program to demonstrate the issue. In Turbo Pascal 5.5
(Downloaded from http://bdn.borland.com/article/0,1410,20803,00.html) this
code generates a 12-byte file. FPC generates a 16-byte file. (Actually,
the preprocessor directives shown appear to have no effect on this
code--not complaining since the docs don't make it appear that it should,
just pointing it out.)
Program testrec;
{$IFDEF FPC}
{$MODE TP}
{$PACKRECORDS 1}
{$ENDIF}
type
realrec = record
t1 : real;
t2 : real;
end;
var
realfile : file of realrec;
r : realrec;
begin
r.t1 := 1.0;
r.t2 := 2.0;
assign ( realfile, 'c:\r.rfl' );
rewrite ( realfile );
write ( realfile, r );
close ( realfile );
end.
Any ideas appreciated!
Thanks,
Lowell C. Savage
[EMAIL PROTECTED]
505-667-6964 (office/msg)
360-961-8965 (cell/msg)
505-667-4341 (shared fax)
Lowell C. Savage
[EMAIL PROTECTED]
505-667-6964 (office/msg)
360-961-8965 (cell/msg)
505-667-4341 (shared fax)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
