Skip to content
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

Open
1 of 3 tasks
penguineer opened this issue Nov 20, 2017 · 5 comments
Open
1 of 3 tasks

Convenience API for configuration handling #9

penguineer opened this issue Nov 20, 2017 · 5 comments
Assignees

Comments

@penguineer
Copy link
Owner

penguineer commented Nov 20, 2017

Extend the API for better configuration handling, such as:

  • Print the current configuration
  • Just load a configuration from file and return the created configuration object
  • Move a pre-loaded configuration object to the agent
@penguineer penguineer self-assigned this Nov 20, 2017
@penguineer
Copy link
Owner Author

Printing has already been started there:

printf("Agent configuration:\n"

Should be moved to a library function.

@penguineer
Copy link
Owner Author

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.

@LeSpocky
Copy link
Contributor

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?

@penguineer
Copy link
Owner Author

The idea is that clean-up is done completely by the library, so handling will be easier for the user.
(Clean-up could take place in some abort routine or at a place where information about the configuration's origin (loaded from file, from command line) is no longer known and would otherwise have to be tracked.)

So,

  • either the users do resource management by themselves, i.e. allocate and free ressources for the agent and the configuration object (which seems kind of redundant)
  • or the user hands pointer ownership to the library (similiar to unique-ptr in C++) and clean-up is done automatically for the configuration object.

I'll propose a solution for both use cases.

@penguineer
Copy link
Owner Author

Resource management has been implemented in #12, which concludes the above discussion for now.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants