Your observation is correct. If the LibVncServer library internally frees the serverIp parameter passed by the user (via the serverHost member), it could indeed be considered a design flaw or a bug. This is because it violates a fundamental principle of resource management: the entity that allocates a resource should be responsible for freeing it.
General Principles of Resource Management
In C/C++ library design, it is customary that if a library accepts a pointer provided by the user, it should not attempt to free this pointer unless the documentation explicitly states that the library will take over the management of that pointer's memory. This approach has several advantages:
Reduces errors and conflicts: Avoids conflicts between the library and the application over memory management.
Provides flexibility: Users can manage resources as needed, such as using custom memory allocators.
Avoids assumptions: The library makes no assumptions about how memory should be managed, making the library more general and stable.
If you'd like to put out an incentive for fixing this bug, you can do so at https://issuehunt.io/r/LibVNC/libvncserver
void rfbClientCleanup(rfbClient* client){
free(client->serverHost);//This is a Bug }
Your observation is correct. If the LibVncServer library internally frees the serverIp parameter passed by the user (via the serverHost member), it could indeed be considered a design flaw or a bug. This is because it violates a fundamental principle of resource management: the entity that allocates a resource should be responsible for freeing it.
General Principles of Resource Management In C/C++ library design, it is customary that if a library accepts a pointer provided by the user, it should not attempt to free this pointer unless the documentation explicitly states that the library will take over the management of that pointer's memory. This approach has several advantages:
Reduces errors and conflicts: Avoids conflicts between the library and the application over memory management. Provides flexibility: Users can manage resources as needed, such as using custom memory allocators. Avoids assumptions: The library makes no assumptions about how memory should be managed, making the library more general and stable.