Is global state evil if it doesn't change behavior?

Question

I have a library in C where the API uses "objects" to interact with the application. These "objects" are opaque pointers that are created, destroyed, and modified via API calls.

These "objects" do not exist in a hierarchy and their lifetimes are loosely managed. As a result, the library has to keep pools of these objects and track of which ones are being used and which ones aren't. This requires that the library has some sort of state for managing these pools.

My current solution use a global state to manage them, like so:

initializeLibrary();
Object *obj = createObject();
//Do something with obj
destroyObject(obj);
terminateLibrary();

However, it's entirely possible to make the library not rely on global state:

Instance *instance = initializeLibrary();
Object *obj = createObject(instance);
//Do something with obj
destroyObject(obj);
terminateLibrary(instance);

My reason for using a global state is that it's easier to read the code when I'm not passing around an instance variable everywhere. Generally the reason given for why global states are bad is that it results in unpredictable behavior, but I don't think that applies here.

My question is whether or not my use of global state is a bad design choice.

Answer 1

Your library needs to keep track which objects are being used why?

Shouldn't it be the responsibility of the owner of those objects to know that information unless there is some context to all of them?

If the objects don't depend on each other then the library shouldn't need to keep track of which ones are being used, that's their owners job.

If there is indeed some context then simply provide that context to the outside world and require its use on the API calls..