Function that takes arbitrary data: Use void* or char*?

Question

I recently wrote a wrapper for LevelDB in C and stumbled about the following problem. The LevelDB function to store data in a database looks like this:

leveldb_put(leveldb_t* db, const leveldb_writeoptions_t* options, const char* key, size_t keylen, const char* val, size_t vallen, char** errptr);

For the key and value, they use a char*. That means I would have to cast arguments that aren't char pointers. This happens often because I often store structs in the database.

After thinking about this I decided to use a void* for key and data in my wrapper function. It then looks something like this:

int db_put(db_t db, void *key, size_t keylen, void *value, size_t valuelen)
{
    char *k = (char*)key;
    char *v = (char*)value;

    /* Call leveldb_put() here with k and v as parameters. */

    return 0;
}

This way I don't have to cast the arguments I pass to my db_put() function. I think this solution is more elegant, but I guess LevelDB knew what they were doing when they choose the char pointers.

Is there a reason not to use void* to pass arbitrary data to a function?

Answer 1

Is there a reason not to use void* to pass arbitrary data to a function?

No. In fact, void * exists to facilitate passing arbitrary data without the need for ugly casting. That's why ptr-to-void was standardized. In C at least. C++ is a different beast.

At LevelDB they have to deal with historical code born with char * , or pre C89 compilers, or any other veiled reason causing refactoring-inertia. Their code would work with ptrs-to-void just as well.

Note that in your version of db_put the casts should be removed as they are redundant.

Answer 2

A void* can be considered a black box that holds a pointer. By holding it in a void* you are effectively saying that you don't care or it contains at that point, so this will allow you to make any assumption about it. Void* is a "true" generic pointer, and can be directly assign to any particular data type without using cast.

Meanwhile, a char* explicitly specify the type of the respective object. Initially there was no char* and char* was also used to represent generic pointers. When char* is used an explicit cast is required, however the usage of char* as a generic pointer is not recommanded, because it may create confusion, like it did back there when it was hard to tell if a char* contains a string or some generic data.

Also, is legal to perform arithmeticon a char*, but not on a void*.

The downside of using void*, is given by their main usage, they can hide the actual type of the data you're storing, which prevents the compiler and other stuff to detect type errors.

In your specific situation there is no problem in using void* instead of char*, so you can use void* without worries.

Edit: Updated and reformuled the answer to correct some wrong info

Answer 3

The current accepted answer exists only to flatter the OP; It's actually slightly invalid.

Consider that your arbitrary struct may (most likely) have padding bytes somewhere. The value of those padding bytes is indeterminate and may or may not be insignificant.

Consider what might happen if you put a struct as key that has padding bytes, and you then attempt to get the value for that key which is otherwise equal except for the padding bytes.

Consider also how you might handle pointer members, if you choose to do so in the future.

If you intend to use a struct as key, it would be a good idea to serialise it, so you can guarantee retrieval of the corresponding value without worrying about those padding bits.

Perhaps you could pass a function pointer telling your wrapper how to serialise the key into a string...

Answer 4

You should be serializing to some standard format like json instead of dealing with raw data like that. It looks very error prone unless you always assume that the arbitrary data is just a byte buffer. In which case I would use uint8_t pointer (which is an unsigned char*) and cast all data structures to it so that the routine just thinks that it is dealing with a byte buffer.

A note on void*: i almost never ever use them. Think carefully when you introduce void pointers because in most cases you can do away with the right way of doing things which takes advantage of the standard types to avoid future bugs. The only places where you should use void* is in places like malloc() where there is not really a better way.