gforth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gforth] ORDER bug


From: Bernd Paysan
Subject: Re: [gforth] ORDER bug
Date: Fri, 25 Nov 2011 23:08:15 +0100
User-agent: KMail/4.7.2 (Linux/3.1.0-1.1-desktop; KDE/4.7.2; x86_64; ; )

Am Donnerstag, 24. November 2011, 19:15:00 schrieb Anton Ertl:
> I have again applied the idea of checking the link field to this new
> 
> head?, resulting in:
> : hybrid-head? ( addr -- f )
> 
> \G heuristic check whether addr is a name token; may deliver false
> \G positives; addr must be a valid address; returns 1 for
> \G particularly unsafe positives
>     \ we follow the link fields and check for plausibility; two
>     \ iterations should catch most false addresses: on the first
>     \ iteration, we may get an xt, on the second a code address (or
>     \ some code), which is typically not in the dictionary.
>     \ we added a third iteration for working with code and ;code words.
>     3 0 do
>       dup new-head? 0= if
>           drop false unloop exit
>       endif
>       dup @ dup 0= if
>           2drop 1 unloop exit
>       else
>           dup rot forthstart within if
>               drop false unloop exit
>           then
>       then
>     loop
>     drop true ;
> 
> This eliminates the three known false positives.  Now we see:
> 
> [~/gforth:76535] gforth xxx.fs -e "hashpop ? testhybrid . cr bye"
> 2989 3014
> 
> So there are 25 words that are recognized but are not in the hash
> table.  Maybe we have that many words in plain linked lists, or maybe
> there are still false positives; I did not find any suspicious words
> among the recognized ones, though.

The only wordlist with slowvoc enabled should be the locals definitions.

> Anyway, I have added this method to our HEAD? check.
> 
> > This should be a pretty strict test, and at least it won't do any harm
> > to do a .name on it, even if it still is a false positive.
> 
> The problem is that the invalid memory access occurred in name>int
> (IIRC), which might still trip over a false positive, unless your CFA
> test excludes this possibility.

Everything done in name>int is checked with my test.  What I would remove is 
the 1 return value ("not sure") when there are less than 3 names in the link 
chain.  Being at the head of a link chain makes it still a legitimate header, 
and this will also catch the most likely false positives: string literals.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]