Ron Frederick ronf@timeheart.net writes:
[Ron] There are other ways to interface to C code in Python that can auto-generate shims to do something like this, but they would involve actually generating and compiling additional C code at build time and shipping an additional C shared library with the Python code, which means multiple versions of the package are needed to cover each of the supported architectures.
That's they way I would expect language bindings to work. And I don't think any other way can work if one aims to have python glue for everything in Nettle.
That said, for umac and other mac algorithms, I think it would make sense to provide structs similar to nettle_hash which includes all needed sizes and function pointers.
Would that solve your problem? You could try to see if you can make 100% python wrapper for the supported hash functions in the nettle_hashes list (I think Daniel Kahn Gillmor did something similar in his perl bindings). I guess you'd still need to access struct members, though. If useful, it's also possible to add accessor functions like
size_t nettle_hash_ctx_size(const struct nettle_hash *hash) { return hash->ctx_size; }
nettle_hash_init_func *nettle_hash_init(const struct nettle_hash *hash) { return hash->init; }
etc. (Other variants are possible, if one aims for a function-call-only api).
And then there's a known ABI problem with exporting that list, discussed in another mail to the list, which needs to be solved in one way or the other.
[Ron] This is a good point. Based on some simple tests, the returned memory always seems to be at least 16-byte aligned similar to malloc(), but I can’t actually find documentation that explicitly promises this. I’ll have to do more research on this.
If you don't find any better way, maybe you can use ctype to call libc malloc directly?
Regards, /Niels