It's an API breaking suggestion but makes library more suitable to use without changes.
The library is designed in a way that it's a client responsibility to open the input FILE as suggested by function
signatures. It's a bit unexpected that the library takes responsibility to close that file when IO is done.
This mixed responsibilities with regard to file IO often results in client code that looks buggy (forgot to close the file).
Usually you expect that either library manages all IO or it's on the client side but not 50/50. Even with the example
provided with a library my first impression was it's an author style to open the file and then intentionally not
to close it assuming that OS will clean up the resources. Only accidentally I found that it's part of the library code.
It's an API breaking suggestion but makes library more suitable to use without changes.
The library is designed in a way that it's a client responsibility to open the input FILE as suggested by function signatures. It's a bit unexpected that the library takes responsibility to close that file when IO is done.
This mixed responsibilities with regard to file IO often results in client code that looks buggy (forgot to close the file). Usually you expect that either library manages all IO or it's on the client side but not 50/50. Even with the example provided with a library my first impression was it's an author style to open the file and then intentionally not to close it assuming that OS will clean up the resources. Only accidentally I found that it's part of the library code.