[getdns-api] getdns_return_t for destroy methods
Paul Hoffman
paul.hoffman at vpnc.org
Mon Mar 10 21:55:57 CET 2014
On Mar 10, 2014, at 8:31 PM, Goyal, Neel <ngoyal at verisign.com> wrote:
> Hopefully an example can clarify what I mean. Get your C hat ready.
> Please consider the following:
>
> getdns_context* context = NULL;
> getdns_context_create(&context, 1);
> // the context variable now points to some location in memory that contains
> // our internal context data
> getdns_context_destroy(context);
> // the memory that context points to has been freed up and cleared.
> // however, the context variable still points to that memory location and
> is
> // not NULL (context != NULL)
>
> So calling getdns_context_destroy(context); again will fault because the
> variable passed in is not NULL, and the code considers it valid. There’s
> no way around this unless we take in a context** and set *context to NULL
> in our destructor.
... or you remember all of the valid values for the pointers to contexts that you already destroyed. I assumed that you were saying you were going to do that in order to know that you should instead return GETDNS_RETURN_GENERIC_ERROR. Instead, you seems to be saying "if we determine that a context cannot be destroyed by where the function is being called, we can give an error". That seems... limited. It would certainly lead some application developers to rely on getting a GETDNS_RETURN_GENERIC_ERROR back where you might not give them one, such as if they already destroyed the context.
This is feeling like you want the error for one use case ("we can see that they're calling the destroyer inside the callback") but are describing it more broadly than it deserves. If that's the case, I'm OK with having an error returned, but certainly not GETDNS_RETURN_GENERIC_ERROR: it would have to be very specific to what you are testing.
Let me know if I have misunderstood.
--Paul Hoffman
_______________________________________________
getdns-api mailing list
getdns-api at vpnc.org
More information about the spec
mailing list