-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: