Ron Frederick <[email protected]> writes: > Rather than adding a function to return the structure size here, what > do you think about adding functions such as umac32_new() which would > do the allocation of the structure and return a pointer to it?
Actually, I think I'd prefer a way to get the struct size at run time; otherwise I'd have to consider interfaces to let an application override the allocation function used by the *_new functions. Are you sure the ctypes package you use doesn't provide any general way to extract struct sizes from a C interface? I know it's common practice to design libraries to have only opaque types, with function calls for allocation, use, and deallocation. But I wouldn't expect nettle to be the only library which tries to be more low-level and expose some internals. For example, if one ever wants to let the python code read or write fields of a struct used in a C interface, then, I imagine, the python glue magic needs to either extract the layout from the header file, or generate a litte C code, including the header file, to get proper sizes and offsets or accesor functions. I think that, in general, it makes little sense to use C code in a shared library without also using the corresponding header file in some way or the other. In principle, the compiler could insert information about sizes and struct layouts (for more general use than just debug info) into the object files, so that the python glue code could extract it from the shared library itself. But as far as I'm aware, common compilers and linkers don't do that. > ctx = ctypes.create_string_buffer(UMAC_CTX_SIZE) Note that nettle's context structs have stricter alignment requirements than a string. Maybe you need to use a different allocation method, to guarantedd you at least as much alignment as the system's malloc? > I really don’t want to rely on a hard-coded size like this, I totally agree that's a bad workaround. /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
