Hi,
On Mon, 2005-06-27 at 10:44 -0400, Rob Richards wrote:
> Kasimier Buchcik wrote:
>
> >
> >The context has just an initial "void * _private" field, to be able to
> >extend it. Adding fields to it, at the end, won't break ABI
> >compatibility.
> >
> >
> How do you not break compatibility? For example, A new field is added,
> which if not NULL would cause the execution of some function while
> inside the adopt node function. If someone where to create a context
> structure, without using some initialization function, then a crash most
> likely would occur as the field is not initialized to NULL.
>
> Like the ctxt->aquireNsDecl(ctxt, cur->ns, &ns) function. When that
> actually gets added, how do I make sure it doesnt execute?
> Will there be a flags field (some int) that indicates the functions off
> the context to execute or will it end up testing:
>
> if (ctxt->flags & DOM_CTXT_AQUIRE_NS) {
> ctxt->aquireNsDecl(ctxt, cur->ns, &ns)
> }
>
> or
>
> if (ctxt->aquireNsDecl) {
> ctxt->aquireNsDecl(ctxt, cur->ns, &ns)
> }
I was thinking of the latter version.
> To avoid breaking stuff, shouldn't an additional function be added which
> returns an initialized context with all fields set to null and be the
> required way to grab the context or run the risk of crashing in future
> releases? This way when a context is needed, they would call the init
> function and then populate their context? As it would be bad if someone
> used the context structure directly not realizing new fields have been
> added and need to be initialized.
Yes, a factory function, e.g. xmlDOMWrapNewCtxt(), which would memset
the structure to 0, should be added.
Regards,
Kasimier
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml