On Tue, 2018-06-26 at 15:34 +0100, Jeremy Harris wrote:
On 06/26/2018 03:29 PM, David Wysochanski wrote:
> On Tue, 2018-06-26 at 09:21 -0400, Dave Anderson wrote:
> > Yes, by default all list entries encountered are put in the built-in
> > hash queue, specifically for the purpose of determining whether there
> > are duplicate entries. So if it's still running, it hasn't found any.
> >
> > To avoid the use of the hashing feature, try entering "set hash off"
> > before kicking off the command. But of course if it finds any, it
> > will loop forever.
> >
>
> Ah ok yeah I forgot about the built-in list loop detection!
For a storage-less method of list loop-detection: run two walkers
down the list, advancing two versus one elements. If you ever
match the same element location after starting, you have a loop.
One problem with all of these non-storage location algorithms is that
it won't give you the precise location of the start of the loop in the
list (i.e. the one with the corrupted 'prev' list entry.
I am not sure if this is a show stopper but that is fairly important
information in most instances.
Attached is my latest patch I was testing.