[DBD-SQLite] Status report

Jonathan Yu jonathan.i.yu at gmail.com
Fri Jul 24 14:25:08 GMT 2009


On Fri, Jul 24, 2009 at 5:24 AM, Dami Laurent
(PJ)<laurent.dami at justice.ge.ch> wrote:
>
>
>>-----Message d'origine-----
>>De : Kenichi Ishigaki [mailto:kishigaki at gmail.com]
>>Envoyé : vendredi, 24. juillet 2009 05:14
>>À : dbd-sqlite at lists.scsys.co.uk
>>Objet : [DBD-SQLite] Status report
>>
>>Hi. As there're several active bug reports and new features,
>>I think it may be useful to make it clear what I'm taking or
>>pending now.
>>
>
> Hi Kenichi,
>
> Thanks for the report.
>
>>1) As Dami's new collation_needed implementation turned out
>>to be leaking badly (as noted in a comment, we should free
>>the struct somehow), I tentatively disabled it, looking for
>>a better implementation (I may also need to disable no_accent
>>collation test which is somehow broken now).
>>
>
> To avoid leaks, the best thing would be to get rid of the struct
> collationNeededInfo, but I'm not sure this is possible. I introduced
> it because collation_needed(...) stores only one single pArg, and
> we need two pieces of information (the callback, and the perl dbh).
> I tried to see if there would be a way to store the perl dbh in
> some private field of the "sqlite3" handle, but it doesn't seem
> to be possible. So if we keep the struct, I think it should be freed
> a) at disconnect; b) if there is a second call to collation_needed(...).
>
> I can volunteer to work on this, but don't know how to detect leaks; what are
> your tools ?
valgrind is great for detecting memory leaks. I also hear frama-c,
which comes with a GUI, is great, though I haven't worked with the
latter extensively.
>
> On the other hand, if no solution is found and collation_needed(..) is dropped,
> then a couple of places need to be adjusted (the whole "COLLATION" section
> in the doc, and the way builtin collations 'perl' and 'perllocale' are installed).
>
>>4) For the improper utf8 tests issue, I'm wondering what's
>>the best solution. Just removing 'require utf8' line is easy
>>and I know the tests work fine without that line, but is
>>that good enough?
>>
>
> As far as I know, this should be good enough. Maybe, for avoiding any
> ambiguity, it would be even better to drop the 'utf8::upgrade(..)' calls,
> replacing them by Encode, or by hardcoded literal strings in utf8 (using \x notation).
>
>
>
> _______________________________________________
> DBD-SQLite mailing list
> DBD-SQLite at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
>



More information about the DBD-SQLite mailing list