[arib06]

blst::Pairing is an empty class whose actual state, the blst_pairing context, lives in the blst_pairing_sizeof() bytes handed out by its class-specific operator new, so it extends well past sizeof(Pairing). The compiler-generated copy constructor and copy assignment still exist, and they copy nothing. As a result new blst::Pairing(*ctx) returns an object whose whole context, DST pointer included, is uninitialized operator-new memory, and deleting it makes ~Pairing() call delete[] on that garbage pointer, while *dst = *src silently leaves dst with its own previous aggregation state. I noticed it while reading the class alongside the Java path that relocates the context, and ASan confirms it with a SEGV in operator delete[] called from ~Pairing (blst.hpp:938) on the copied object. Deleting both special members turns these uses into compile errors and suppresses the implicit move members as well; they sit in the existing #ifndef SWIG block next to operator new/delete, so the SWIG interface is unchanged and the Python and node.js run.me tests still pass. Declaring a Pairing with automatic storage overflows the stack in the same way and is not addressed here, since preventing that would take an interface change.

[dot-asm]

Good point, thanks!