Im actually embedding this in place of leveldb, in a project im working, because i just want a compact db file, and not several like leveldb use to do, and giving the benchmarks are saying this is even faster, its a plus..
But i was just worried about the api using void pointers to represent heap state like db, cursor, etc.. im not a security expert but isnt that considered harmful? giving it could be used as a cursor to point to any arbitrary memory address by a black hat? (or that work just if the handle points to a invalid address? in a bug for instance?)
While it is unfortunate they don't use forward-declared structs instead of void pointers, that only means that potential type checking that could otherwise be done by the compiler does not happen, the use of void pointers in and of itself is not a bug, it just can make it more likely that code using the library won't know about bugs until too late.
This, so much this, but also some of how proper DB modeling and not being afraid of denormalization can really let you solve lots of problems in efficient-enough ways with SQLite and/or MySQL / Postgres.
I tried out a few different mongo db-like embedded DBs for Python for a project a few months back, and I came away largely unimpressed. I ended up using couchdb for the PoC, later moving to ElasticSearch and letting that handle the "hard" parts for me (aggregations, JS in queries, and rivers are awesome). Even though it's hugely overkill for my data needs (~100mb uncompressed JSON), ElasticSearch is stupid fast and now handles a big part of what my app actually did. Embedded DBs couldn't do the same.
But i was just worried about the api using void pointers to represent heap state like db, cursor, etc.. im not a security expert but isnt that considered harmful? giving it could be used as a cursor to point to any arbitrary memory address by a black hat? (or that work just if the handle points to a invalid address? in a bug for instance?)