libtidy.x86_64: W: shared-lib-calls-exit /usr/lib64/libtidy.so.5.0.0 exit@GLIBC_2.2.5

[mcepl]

This library package calls exit(3) or _exit(2), probably in a non-fork() context. Doing so from a library is strongly discouraged - when a library function calls exit(), it prevents the calling program from handling the error, reporting it to the user, closing files properly, and cleaning up any state that the program has. It is preferred for the library to return an actual error code and let the calling program decide how to handle the situation.

[geoffmcl]

@mcepl as far as I remember the only place libtidy uses exit is in the default memory allocators/re-allocators... there is no way such a memory service can return an error code, a NULL in this case, to the caller... nor can all callers to the service be adjusted to politely 'exit', or do something else, if a NULL passed back... so this stays, discouraged or not!

However, if some other software uses the libtidy, it can choose to replace the default allocators, with its own allocators, see tidyCreateWithAllocator, and choose to do what it wants if the OS returns a NULL... So it is possible for such a user of libtidy to fix this in their own way.

As to be expected there may be others in the Debug builds... that is specifically if -DNDEBUG is not defined in the compile, there are quite a number of asserts in the library, which I think also lead to an exit if fired. Of course, none should... But by specifying -DCMAKE_BUILD_TYPE=Release these assert compile to nothing.

And there are some more in the WIN32 Debug build, in the sprtf.c module. But this module is again ONLY used in the windows Debug build... and not part of the Release library...

So at this time I do not see this as a 'bug' in the library, but will leave the issue open a while for further comment, if any...

[mcepl]

OK, feel free to close this. I get this warning even with -DCMAKE_BUILD_TYPE:STRING=Release, but you are right, it might be that malloc.

[geoffmcl]

@mcepl I have now had a chance to carefully search the full library sources, and can confirm the only exit(2) is in the defaultPanic() service.

And the documentation for Memory Allocation makes specific mention of this exit IIF the default panic is used. And adds a clear note from tidy.h:

For applications in which it is unacceptable to abort in the case of memory allocation, then the panic function can be replaced with one which longjmps() out of the tidy code. For this to clean up completely, you should be careful not to use any tidy methods that open files as these will not be closed before panic() is called.

Is there not a way to suppress this warning?

Anyway, closing this for now... thanks...