No corresponding buffer free function for C API leveldb_get

[cmumford]

Original issue 117 created by albert.jin on 2012-09-18T13:21:35.000Z:

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

There should be a free function provided by the library. When leveldb is build as a shared library, the consumer of this library could be built by any other compile with its own free() function.

I would like to suggest that a new API "void leveldb_free(char* buffer)" be added.

What version of the product are you using? On what operating system?

1.5.0 on all platforms

Please provide any additional information below.

[cmumford]

Comment #1 originally posted by albert.jin on 2012-09-18T14:38:56.000Z:

Note that this free function should also be used to free the error info returned from leveldb_open()/leveldb_destroy_db() and the return from leveldb_property_value().

[cmumford]

Comment #2 originally posted by sanjay@google.com on 2012-09-18T15:55:04.000Z:

Sorry, but I am not inclined to widen the API for such an obscure use case.

Note that you should be able to deal with this by changing your link order so that leveldb code uses the same malloc() routine that corresponds to your free(). In fact, I am confused as to how you could reasonably expect to work in a situation where there are multiple active memory allocators. For example, what happens if either your code or leveldb code calls strdup(). That will go into libc and use whatever malloc() libc ends up resolving to. But the result will be passed to your code which will end up calling your custom free().

[cmumford]

Comment #3 originally posted by kkowalczyk on 2012-09-18T18:58:33.000Z:

Just FYI: this is very linux-centric attitude.

The problem described by Albert is very common on Windows, where it's customary to build a DLL with compiler X and that DLL will be used by code compiled with compiler Y. That's why I had to write leveldb_free() in my Windows port (https://code.google.com/r/kkowalczyk-leveldb/source/browse) - I've seen this problem many times in the past and I know that it has to be properly addressed on Windows.

By not adding this you're effectively saying: on Windows, it's not possible to provide binary distribution of Leveldb as a DLL.

Esoteric case? Consider hypothetical leveldb Python bindings that someone might want to provide for Windows Python. They couldn't.

The only way to do that by a 3rd party is to provide leveldb as a DLL and necessary Python wrapper code. 3rd party cannot know (nor should they) what compiler was used to build Python. Not to mention that python.org folks might use a different compiler than ActiveState folks and version 2.7 might be built with a different compiler than 3.2.

Or C# bindings - again, not possible.

As to your hypothetical strdup() scenario: you can't do it (if you want to support leveldb as a Windows DLL). The memory allocated by leveldb has to stay within leveldb code or, if it escapes to the user code, a function must be provided to free it inside leveldb code (hence the need for leveldb_free).

Hope you'll reconsider.

[cmumford]

Comment #4 originally posted by sanjay@google.com on 2012-10-08T20:56:46.000Z:

Ok. Will add "void leveldb_free(void*)" to the C binding.

[cmumford]

Comment #5 originally posted by sanjay@google.com on 2012-10-12T19:57:55.000Z:

Fixed in 1.6.0. Added leveldb_free(void*) function to C binding.