Re: [PATCH 0/3] Fix NULL deref through valuePop retval
Jan Pokorný <[email protected]> Thu, 26 Dec 2013 16:32:53 +0100
| Newsgroups | gmane.comp.gnome.lib.xslt |
|---|---|
| Message-ID | <[email protected]> |
On 20/12/13 18:17 +0100, Nick Wellnhofer wrote: > On Dec 20, 2013, at 00:48 , Nick Wellnhofer <[email protected]> wrote: > >> I think this should be fixed in libxml2. The following patch works >> for me but I’ll have to give the whole thing a closer look. > > I committed a modified version of that patch to libxml2: > > https://git.gnome.org/browse/libxml2/commit/?id=03c6723043775122313f107695066e5744189a08 > > I also added Jan's test case to libxslt: > > https://git.gnome.org/browse/libxslt/commit/?id=683cbc82dee4cea75822a0f7cafd97768b6165ff Thanks Nick; indeed I know much less about lib{xml2,xslt} internals (and tried to be explicit about the necessity to explore the relevant code paths more thoroughly) so I am happy that one-off generic solution emerged. > It still might be a good idea to check the return values of valuePop() > as a safety measure. Seems not actual anymore, unless it would make sense to turn such checks to assert clauses disabled upon non-debug build ... which may not be good practice for a library anyway. As you wrote, relying on natural (and ideally also explicit) guarantees/conventions seem a better fit within such an internal handling where everything is under single point of control and hence paranoid double+ checks are not really needed. The only downside is it's hard to maintain that apparent guarantees for pieces are preserved also for their arbitrarily convoluted composition (which is what went wrong in this instance, IIUIC). Cheers and HNY -- Jan _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] https://mail.gnome.org/mailman/listinfo/xslt