mirror of
https://github.com/facebook/rocksdb.git
synced 2024-11-28 05:43:50 +00:00
54cb9c77d9
Summary: The following are risks associated with pointer-to-pointer reinterpret_cast: * Can produce the "wrong result" (crash or memory corruption). IIRC, in theory this can happen for any up-cast or down-cast for a non-standard-layout type, though in practice would only happen for multiple inheritance cases (where the base class pointer might be "inside" the derived object). We don't use multiple inheritance a lot, but we do. * Can mask useful compiler errors upon code change, including converting between unrelated pointer types that you are expecting to be related, and converting between pointer and scalar types unintentionally. I can only think of some obscure cases where static_cast could be troublesome when it compiles as a replacement: * Going through `void*` could plausibly cause unnecessary or broken pointer arithmetic. Suppose we have `struct Derived: public Base1, public Base2`. If we have `Derived*` -> `void*` -> `Base2*` -> `Derived*` through reinterpret casts, this could plausibly work (though technical UB) assuming the `Base2*` is not dereferenced. Changing to static cast could introduce breaking pointer arithmetic. * Unnecessary (but safe) pointer arithmetic could arise in a case like `Derived*` -> `Base2*` -> `Derived*` where before the Base2 pointer might not have been dereferenced. This could potentially affect performance. With some light scripting, I tried replacing pointer-to-pointer reinterpret_casts with static_cast and kept the cases that still compile. Most occurrences of reinterpret_cast have successfully been changed (except for java/ and third-party/). 294 changed, 257 remain. A couple of related interventions included here: * Previously Cache::Handle was not actually derived from in the implementations and just used as a `void*` stand-in with reinterpret_cast. Now there is a relationship to allow static_cast. In theory, this could introduce pointer arithmetic (as described above) but is unlikely without multiple inheritance AND non-empty Cache::Handle. * Remove some unnecessary casts to void* as this is allowed to be implicit (for better or worse). Most of the remaining reinterpret_casts are for converting to/from raw bytes of objects. We could consider better idioms for these patterns in follow-up work. I wish there were a way to implement a template variant of static_cast that would only compile if no pointer arithmetic is generated, but best I can tell, this is not possible. AFAIK the best you could do is a dynamic check that the void* conversion after the static cast is unchanged. Pull Request resolved: https://github.com/facebook/rocksdb/pull/12308 Test Plan: existing tests, CI Reviewed By: ltamasi Differential Revision: D53204947 Pulled By: pdillinger fbshipit-source-id: 9de23e618263b0d5b9820f4e15966876888a16e2 |
||
|---|---|---|
| .. | ||
| lock | ||
| optimistic_transaction.cc | ||
| optimistic_transaction.h | ||
| optimistic_transaction_db_impl.cc | ||
| optimistic_transaction_db_impl.h | ||
| optimistic_transaction_test.cc | ||
| pessimistic_transaction.cc | ||
| pessimistic_transaction.h | ||
| pessimistic_transaction_db.cc | ||
| pessimistic_transaction_db.h | ||
| snapshot_checker.cc | ||
| timestamped_snapshot_test.cc | ||
| transaction_base.cc | ||
| transaction_base.h | ||
| transaction_db_mutex_impl.cc | ||
| transaction_db_mutex_impl.h | ||
| transaction_test.cc | ||
| transaction_test.h | ||
| transaction_util.cc | ||
| transaction_util.h | ||
| write_committed_transaction_ts_test.cc | ||
| write_prepared_transaction_test.cc | ||
| write_prepared_txn.cc | ||
| write_prepared_txn.h | ||
| write_prepared_txn_db.cc | ||
| write_prepared_txn_db.h | ||
| write_unprepared_transaction_test.cc | ||
| write_unprepared_txn.cc | ||
| write_unprepared_txn.h | ||
| write_unprepared_txn_db.cc | ||
| write_unprepared_txn_db.h | ||