Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overhauling OQS_MEM functions #1766

Open
Martyrshot opened this issue Apr 23, 2024 · 0 comments
Open

Overhauling OQS_MEM functions #1766

Martyrshot opened this issue Apr 23, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@Martyrshot
Copy link
Member

As part of the sig-stateful review I had a few thoughts on how we handle our OQS_MEM functions.

Update OQS_MEM_*_free functions to take double pointers

Firstly, our OQS_MEM_*_free set of functions currently takes a single pointer:

OQS_API void OQS_MEM_insecure_free(void *ptr)
OQS_API void OQS_MEM_secure_free(void *ptr, size_t len)

This follows the c standard library's convention which is nice! However, this makes double frees possible and hard to identify.

If we update the free functions to use a double pointer, then we can set the pointer to point to NULL before the function exists.

OQS_API void OQS_MEM_insecure_free(void **ptr)
OQS_API void OQS_MEM_secure_free(void **ptr, size_t len)

There are two scenarios this helps:

Debugging

OQS_MEM_insecure_free(&my_cool_ptr);

... some operations later ...

// This line will segfault instead of double freeing, making the actual bug easier to find.
OQS_MEM_INSECURE_free(&my_cool_ptr);

Conditional freeing

OQS_MEM_insecure_free(&my_cool_ptr);

... some operations later ...

if (my_cool_ptr != NULL) {
    OQS_MEM_insecure_free(&my_cool_ptr);
}

By taking a double pointer we make it harder for users of OQS_MEM_* to do something incorrectly.

Add OQS_MEM wrapper for malloc

Currently, as silly as it seems, ISC_MEM_*_freeing a chunk of memory allocated by malloc feels wrong. In other c projects I work in memory that is freed by their provided free functions must have come from their own malloc/alloc functions. This is because they may be providing a custom allocator under the hood. Although OQS doesn't do anything like this, I think that adding a malloc wrapper under the OQS name space would be beneficial for two reasons:

  1. It makes it obvious that a chunk of memory can be freed with our OQS_MEM_*_free functions
  2. It gives us the flexibility in the future to add custom memory management should we decide this is needed

For now, the macros below would work, but in the future we could define an actual function that checks for null etc.

#define OQS_MEM_malloc(ptr, sz) ptr = malloc(sz)

What do you think?

@SWilson4 SWilson4 added the enhancement New feature or request label Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants