-
Notifications
You must be signed in to change notification settings - Fork 1
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
Convenience API for configuration handling #9
Comments
Printing has already been started there: Line 202 in 055f435
Should be moved to a library function. |
Moving pointers into the object leads to a problem when pointers have not been created with malloc: The library will try to free the pointer, but fails (with undefined behaviour) on stack pointers. However, it is a common pattern to provide this structure via stack pointer (from a local or static variable). I wonder if a warning in the API documentation is sufficient to keep developers from just providing a pointer to a stack variable or if there should be a mechanism to distinguish these, i.e. have two functions and a flag to denote whether the pointer must be free'd. |
Why should the library free things it did not allocate by itself anyway? That should always be responsibility of the caller. So: if the library allocates some config object by itself (maybe a copy of an existing object), the library can free it again unless otherwise documented. I would say freeing things allocated outside of a library is bad practice? |
The idea is that clean-up is done completely by the library, so handling will be easier for the user. So,
I'll propose a solution for both use cases. |
Resource management has been implemented in #12, which concludes the above discussion for now. |
Extend the API for better configuration handling, such as:
The text was updated successfully, but these errors were encountered: