[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Jul 2012 17:46:31 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: magnum-jumbo and magnum-bleeding (NOT J7), and the source() function
>From: magnum [mailto:john.magnum@...hmail.com]
>
>On 2012-07-09 17:50, jfoug wrote:
>> What direction should the fmt.methods.source() (currently named
>> get_source) function take?
>>
>> I would propose this.
>>
>> 1. Rename it to source() (how Solar wants it). Also change any
>> documentation, and -list= data to reference source
>>
>> 2. Move it to right after salt, this would be a more 'fitting'
>> location. Currently in bleeding, it is at the bottom of the
>> structure, but I simply put it there to get NULL pointers during early
>> implementation, so I would not have to modify every _fmt.c file.
>
>Fine with me.
I still want to hear from Solar, on what/how this will be done in core, just
so it can be done that way in jumbo-bleeding (or whatever tree), in the
first place. Then, there is no porting needed, by the time core gets this
method implemented.
I do think the interface for source() (or get_source(), or foo_bar() or
whatever) is good. Passing in the db_password structure pointer, and then
'using' the salt pointer in multiple ways, makes calling source() very easy
to do, almost a direct replacement for the original pw->source pointer, AND
saves memory, in not wasting space even for another pointer. Also, passing
in the buffer is pretty much needed, since that allows this function to be
called from multi-threaded code. I am not 'sure' it will be called from MT
code, but it certainly could be.
Jim.
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.
