[getdns-api] A couple of more changes
Willem Toorop
willem at nlnetlabs.nl
Wed Nov 20 21:12:35 CET 2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
op 20-11-13 17:06, Matt Miller schreef:
>
> On Nov 20, 2013, at 8:54 AM, Willem Toorop <willem at nlnetlabs.nl>
> wrote:
>
>> op 20-11-13 16:30, Paul Hoffman schreef:
>>> On Nov 19, 2013, at 8:45 PM, Melinda Shore
>>> <melinda.shore at nomountain.net> wrote:
>>>> 2) From the sync functions we'd like to remove the the
>>>> response_length parameter and pass the response parameter by
>>>> reference (**response rather than *response)
>>>
>>> If you do #2, you need to add a new error that say "I couldn't
>>> allocate enough memory to give you a response", and you should
>>> document that you will not give partial responses in that case.
>>> (Please don't say "if **response is NULL, that tells you that
>>> it failed"; that's too 90's for this spec.)
>>
>> +1
>
> As long as the memory allocation and deallocation stay at the same
> API layer (if it gets allocated by getdns, then it gets deallocated
> by getdns), this makes a lot of sense to me.
Of course. They inherit memory functions from the context and the
dict_destoy will use that deallocator.
B.t.w. I understand the semantics implied by the other signature;
response_length would go in as the length of the buffer pointed to by
response and goes out with the number of bytes actually used, but this
is not mentioned in the API specification and the examples did not
illustrate this type of usage. It would be inconvenient for JIT
parsing response dicts as well (because of "just in time" needed extra
allocations etc).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSjRezAAoJEOX4+CEvd6SY2bkP/REGLwTYhr2GCAswcYRfDZ32
6H2FUzvKwoz3BR+VCXY3zhjWG6BW00klkUxV3KjEV/m8SRw3cQ5EPZNY0l8iRXPP
AE9ybkuawE6FT0QbV0xRqMZtQfp5JJs8jhSygk+2VzsCHLRkGhN3kY4NCL/J9NS3
LBgZg6p3mzRaFTV73sj0tYAWq3K03l4G9XNXCgmPXwFTeJuleexkiMWQL17mkdwZ
u1m1stHsHegqypIvfAul60MRYioLoy72RnExf3kr4R/6XANKdopuqaKFKRKwXP4X
kQpPodDlaJg2CO8FdsSpvQ+jGCdzfu3bTvpdERHdyulNS4Fmva1qZ4A6sio7oTbR
3aaMZBD3FawwVoSWaJVY8z05HrP0GFjBULzO0sdWFO4CMApipeQXlXmtzzaUE2lF
sHpAWwezMrYAL11k7+T5hLN2U4Dfopcp1EsV66bazFG/5O7kLAkQ1RPZtJ/KOHqI
XiNuU8vXYNwhA7qN5/31UvIipCkAnbJ6M8n/8VRAQ1BlRMQkitImstBBGuETP/ch
Htc43YJ4g+IeLTL27/ilYWMyRN2T4zChIO3/IDPt5glkmunkqi6NrP11Yb9z/1zi
UkOAk1WVzY0Bp09MLq5ojt6pJ825ymCWOPe72PSiJAncOWEhXNrLo7jTEZeA3vJE
oEdmoxGsPfuTbXQXifv9
=60kO
-----END PGP SIGNATURE-----
_______________________________________________
getdns-api mailing list
getdns-api at vpnc.org
More information about the spec
mailing list