Repository navigation
Sound API Design: bytemuck::Pod
I'm currently leveraging bytemuck::Pod for a lot of data, despite said data being sent over obstensibly opaque ABI boundaries through Direct3D virtual function calls. It's so very incredibly tempting to weaken some trait boundaries to being merely Copy. However, this would technically be unsound. While it's hard to imagine any resulting misbehavior, it's not impossible:
Generally, calls into Direct3D cross an opaque ABI boundary, limiting the potential for optimizer miscompiles triggered by reading uninitialized data.
However, this isn't actually strictly guaranteed. If something similar to ANGLE or d3d8to9 were to be statically linked into your executable, and it were to translate Direct3D APIs that thindx targets, and if the optimizer were able to do a good enough job of devirtualizing the calls... it's entirely possible that link time optimization might allow optimizer misbehavior around copying "uninitialized" data.
Direct3D generally won't be compiled with AddressSanitizer, although a proxy version like mentioned above could be. However, intrusive recompiles like that aren't the only option - some allocators/APIs might align the start of uninitialize data with the end of a heap page for the purpouses of helping debug heap overruns. Reading said data would then result in an access violation / page fault. Additionally, a perhaps more insidious killer would be stack guard pages - uninitialized stack data could theoretically avoid triggering e.g. _chkstk / stack growth until initialization is actually requested.
No, really, the full guarantees of a bytemuck::Pod are in fact, actually, technically, necessary.