[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACYkhxi3QO7_kwp4nJMn0+adg36yphkbvPSM+H1qEmGFo-iNqA@mail.gmail.com>
Date: Fri, 14 Jun 2013 11:15:48 +1000
From: Michael Samuel <mik@...net.net>
To: john-users@...ts.openwall.com
Subject: Re: Resume for KDEPaste external mode
I think all variables should probably be saved - they're global for a
reason, right?
That being said, there is a chance that the state could be recovered from
word in this case...
On 14 June 2013 11:09, magnum <john.magnum@...hmail.com> wrote:
> On 13 Jun, 2013, at 0:41 , Solar Designer <solar@...nwall.com> wrote:
> > On Wed, Jun 12, 2013 at 11:57:41PM +0200, magnum wrote:
> >> On 12 Jun, 2013, at 23:45 , magnum <john.magnum@...hmail.com> wrote:
> >>> KDEPaste lacks a restore() function. If you resume it, it will just
> restart from scratch. My first question is: Should this not be detected and
> resulting in refusal to resume? Or could some modes work fine without a
> resume() function? I guess some could... but at least we should warn or
> something?
> >>
> >> On second thought I really think it should bail out with error. Modes
> that don't really need any special code should implement a dummy restore().
> I will try implementing this in Jumbo and see where it goes but it should
> be in core too IMHO.
> >
> > There are definitely external modes that are --restore'able even though
> > they lack a restore(). Warning when there's no restore() and adding a
> > dummy restore() to those formats to suppress the new warnings is an
> > interesting idea.
>
> It's in bleeding now. I'd rather bail out than just warn though - when you
> see the warning your .rec file is already screwed. AFAIK we have no
> external mode that [has generate() but] lacks restore() and anyone having
> their own would just have to add a dummy restore().
>
> > I was also thinking of some way to make interrupt/restore of external
> > modes easier - such as by introducing a way to declare external mode
> > variables that would be automatically saved and restored (maybe have
> > "static" mean this, or introduce a keyword of our own - e.g., "restore").
> > In terms of implementation, we could either traverse the variables list
> > and save/restore the needed ones - or we could have these placed in a
> > separate memory region, which would be saved/restored in its entirety.
>
> I like "static". Maybe I can pull that off too.
>
> magnum
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
