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

Feature Inquiry: extra unity_memory support non-symmetric malloc and free #765

Open
vhexl opened this issue Jan 23, 2025 · 2 comments
Open

Comments

@vhexl
Copy link

vhexl commented Jan 23, 2025

I'm currently using the Unity unit testing framework for my C projects and find it really helpful. I was wondering if there are any plans in the future to support asymmetric memory allocation and deallocation functions? This feature could be extremely useful in some specific scenarios where we need more fine-grained control over memory management during unit testing.
If it's not in the current roadmap, could you please consider adding it? It would greatly enhance the capabilities of the Unity framework and benefit many users like me.
Thank you very much for your time and consideration.

@mvandervoord
Copy link
Member

@vhexl -- I assume you're talking about the unity_memory files in extras? By non-symmetric, are you suggesting that instead of verifying the answer is zero at the end of each test, you have the option to specify a number of mallocs / frees that occurred, or something like that?

@vhexl
Copy link
Author

vhexl commented Jan 24, 2025

Yes, I meant ./extras/unity_memory, I tried using this extra to test some memory issues with queues, for queues malloc and free were not always symmetric, causing heap_index to not be 0, and I had to set a large UNITY_INTERNAL_HEAP_SIZE_BYTES size to make malloc work.

My code has an interface like this to use unity_malloc and unity_free

void *_port_malloc(size_t s)
{
    return unity_malloc(s);
}
void _port_free(void *p)
{
    unity_free(p);
}

About heap_index

static size_t heap_index;

By the way, maybe "heap_index" can be used as a heap memory "water mark"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants