Ensure long data column buffers are freed #306
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The bind_type of the column stored in the StatementData object was not copied over to the ColumnData object created for each row. This means that the ColumnData destructor will not free the allocated buffer used with SQLGetData.
Additionally, for SQL_C_BINARY columns, the data was never freed either since the destructor only checked for SQL_C_CHAR and SQL_C_WCHAR.
Finally, because long data allocations are created using malloc/realloc, we need to set a flag to use free instead of delete[] in the destructor. On platforms we support, this shouldn't actually make any difference, but it is mandated by the spec and reduces noise in valgrind.
Signed-off-by: Kevin Adler [email protected]
Fixes #304