[getdns-api] getdns_return_t for destroy methods

Wiley, Glen gwiley at verisign.com
Fri Mar 7 10:09:15 CET 2014


That is a great idea – I like the fact that the signatures become more consistent with the rest of the library as well.
--
Glen Wiley
KK4SFV
Sr. Engineer
The Hive, Verisign, Inc.

From: <Goyal>, Neel <ngoyal at verisign.com<mailto:ngoyal at verisign.com>>
Date: Thursday, March 6, 2014 11:26 AM
To: "getdns-api at vpnc.org<mailto:getdns-api at vpnc.org>" <getdns-api at vpnc.org<mailto:getdns-api at vpnc.org>>
Subject: [getdns-api] getdns_return_t for destroy methods

Hello,

I would like to propose that we change the signatures of the destroy routines such that they return getdns_return_t.

  *   getdns_return_t getdns_context_destroy
  *   getdns_return_t getdns_dict_destroy
  *   getdns_return_t getdns_list_destroy

This would especially be useful in getdns_context_destroy since implementations may decide that destroying a context within a callback is allowed or not.  There are some fun edge cases we’ve been dealing with regarding this.  Also, it keeps the API consistent with the other methods.

Thoughts?

Neel
“This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://getdnsapi.net/pipermail/spec/attachments/20140307/fd2c26d2/attachment.html>
-------------- next part --------------
_______________________________________________
getdns-api mailing list
getdns-api at vpnc.org


More information about the spec mailing list