AvalonTools: Avoid that trailing garbage pollutes the fmemopen buffer #5928
Conversation
| @@ -36,6 +36,16 @@ if(needDownload) | |||
| WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}) | |||
| endif() | |||
|
|
|||
| set(reaccsio_c "${AVALONTOOLS_DIR}/src/main/C/common/reaccsio.c") | |||
There was a problem hiding this comment.
Is this really a better way of solving this than using a traditional patch?
There was a problem hiding this comment.
@greglandrum No, it isn't. But it is cross-platform as it is supported by CMake, while patch is not available on Windows and it is not supported by CMake. I also hope this is only a temporary solution until a new version of Avalon becomes available upstream.
greglandrum
changed the title
|
@ptosco I just noticed that this runs every time you run cmake. So we end up with multiple definitions of |
|
@greglandrum Yes, I noticed that yesterday and already submitted a PR to fix it: #5951. |
ah, awesome. Thanks. |
Co-authored-by: Tosco, Paolo <paolo.tosco@novartis.com>
I found another issue connected with the usage of
fmemopen()in Avalon which causes a number of tests involving AvalonTools to fail.What happens is that, since almost always the buffer used by
fmemopen()is larger than the actual bytes written, some trailing garbage is left after the expected content, because thefgetswhileloop only looks for EOF, and EOF is only met when the end of the buffer is hit (which will always come after the end of the actual content).The solution is to write a
‘\0’character after the expected content, and in thefgetswhileloop also check for zerostrlenin addition to checking for EOF.I have already submitted a patch to Bernd, but until this is fixed upstream we'd better fix it in the RDKit build.