[getdns-api] string from dict bindata

Tom Pusateri pusateri at bangj.com
Mon May 2 20:55:58 UTC 2016

> On May 2, 2016, at 5:06 AM, Willem Toorop <willem at nlnetlabs.nl> wrote:
> Op 02-05-16 om 02:40 schreef Melinda Shore:
>> On 5/1/16 12:14 PM, Tom Pusateri wrote:
>>> Are we supposed to peek inside of bindata and assume the bytes and
>>> length are string data?
>> Yes, unfortunately you need to know what type of data
>> are being returned in each dictionary element, but if you
>> do it's extremely reliable.  bindata->size holds the
>> string length.  I've found that bindata strings do not
>> always have a terminal \0, so in the Python bindings I'm
>> doing string conversions using PyString_FromStringAndSize()
>> rather than just PyString_FromString().
> That is correct, the internally used getdns_dict_util_set_string() does
> not copy the terminating \0 character, because the string length is
> already provided in bindata.size.
> Note that in our implementation of the API we provide some non-standard,
> but more C-friendly functions to access the version information in
> getdns_extra.h, that do return \0 terminated strings:
> const char *getdns_get_version(void);
> uint32_t getdns_get_version_number(void);
> const char *getdns_get_api_version(void);
> uint32_t getdns_get_api_version_number(void);
> It also contains some macros providing the version information of the
> library used at compile time:
> #define GETDNS_VERSION "1.0.0b1"
> #define GETDNS_NUMERIC_VERSION 0x00100100
> #define GETDNS_API_VERSION "December 2015"
> #define GETDNS_API_NUMERIC_VERSION 0x07df0c00
> -- Willem

Thanks Willem. For the version info, this is helpful. I was just using the api info as an example. I will also have to get strings from TXT records which are more generic.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.getdnsapi.net/pipermail/spec/attachments/20160502/66854b33/attachment.bin>

More information about the spec mailing list