3 ms·

The C++ code in the previous version was already C-style anyway (and nothing wrong with that), and returning pointers from the API would have been a very likely

The C++ code in the previous version was already C-style anyway (and nothing wrong with that), and returning pointers from the API would have been a very likely cause for memory corruption problems if the API is 'misused'. It's more likely that the new handle-based API will improve memory safety drastically (assuming they're tagged index handles which provide both spatial and temporal memory safety at the cost of minimal runtime overhead for each API call which needs to convert handles to pointers - which costs a range check, a tag comparison, and an array indexing operation).

pjmlp 4y ago
It is like asserting using C structs with function pointers is safer than a C++ struct with member functions.
- flohofwoe 4y ago
  I don't understand? Why would function pointers or member functions be involved in a plain C API (unless you want to create one of those ugly "let's wrap an OOP C++ API in a C API" attempts where each C++ method maps to a C function with a "this" parameter or have "virtual function tables" - essentially emulating C++ in C, which really doesn't make much sense). As for the memory safety aspects: When returning raw pointers to internal objects from an API, those pointers can become dangling. C++ smart pointers are not a solution because those cannot be expressed through a C API for language bindings - also there's the question what type of smart pointer to return - unique vs shared? That should be up to the API user, not dictated by the API. Tagged index handles solve all those problems in a very elegant way - and they work equally well for C, C++ or any other language that supports arrays, and since those handles are essentially just integers, they are trivial to tunnel through FFI (see for instance: https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html)
  - pjmlp 4y ago
    It is hardly better than having opaque handles that translate into C++ classes, with proper validation of invariants. I know how well they work in C, having worked on a RPC server for IVR/CRM middleware using similar approach for shared memory IPC across UNIX/Windows multiprocess, and having my share of fixing memory corruption issues in collaboration with our QA team nicely written attack tests in Rational Robot. I guess instead of using Purify and BoundsChecker, now the fun will be with ASAN.

pjmlp 4y ago

It is like asserting using C structs with function pointers is safer than a C++ struct with member functions.

flohofwoe 4y ago
I don't understand? Why would function pointers or member functions be involved in a plain C API (unless you want to create one of those ugly "let's wrap an OOP C++ API in a C API" attempts where each C++ method maps to a C function with a "this" parameter or have "virtual function tables" - essentially emulating C++ in C, which really doesn't make much sense). As for the memory safety aspects: When returning raw pointers to internal objects from an API, those pointers can become dangling. C++ smart pointers are not a solution because those cannot be expressed through a C API for language bindings - also there's the question what type of smart pointer to return - unique vs shared? That should be up to the API user, not dictated by the API. Tagged index handles solve all those problems in a very elegant way - and they work equally well for C, C++ or any other language that supports arrays, and since those handles are essentially just integers, they are trivial to tunnel through FFI (see for instance: https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html)
- pjmlp 4y ago
  It is hardly better than having opaque handles that translate into C++ classes, with proper validation of invariants. I know how well they work in C, having worked on a RPC server for IVR/CRM middleware using similar approach for shared memory IPC across UNIX/Windows multiprocess, and having my share of fixing memory corruption issues in collaboration with our QA team nicely written attack tests in Rational Robot. I guess instead of using Purify and BoundsChecker, now the fun will be with ASAN.