> slugging through the depths of hell where only a footnote from Raymond Chen himself will save you
The behavior is well documented: https://docs.microsoft.com/en-us/cpp/build/x64-calling-conve...
the caller must allocate memory for the return value and pass a pointer to it as the first argument. The remaining arguments are then shifted one argument to the right. The same pointer must be returned by the callee in RAX
So either there's some extra COM consideration I'm not aware of, or there's a serious confusion in how calling conventions work. If someone returns an aggregate, what option do you have other than a pointer? If it's a callee-allocated pointer, what are the lifetime rules and how do you free it? Passing caller-allocated storage is the obvious answer and is far from unusual, or undocumented.
The difference I can tell between the MSVC and Itanium C++ ABIs is just that MSVC uses "this, ret" order for methods, and Itanium uses "ret, this". There's probably some subtle differences in what constitutes "non-trivial" between the two ABIs as well.
VC++ documentation says structures are returned through a caller-allocated pointer. Pretty sure modern VC++ optimizes that thing when it can, especially with link time code generation enabled, but for functions and COM methods imported from DLLs that’s not an option.
System V http://c9x.me/compile/doc/abi.html only classifies values as MEMORY when they exceed 16 bytes. The D3D12_CPU_DESCRIPTOR_HANDLE only has a single size_t field, and therefore returned in RAX register in that convention. Moreover, a structure of two size_t fields would be returned in RAX + RDX registers.
Once upon a time I made this library https://github.com/const-me/comlightInterop/ The native side of the interop is idiomatic C++, here’s an example https://github.com/Const-me/ComLightInterop/blob/master/Demo... The C# side of the interop is implemented through the built-in C interop, here’s the relevant part of the library https://github.com/Const-me/ComLightInterop/blob/master/ComL... I’ve tested Linux version of that library on AMD64, ARMv7, and ARM64 CPUs, but only with gcc compiler on the native side.
If you look at godbolt/or disassembly output of an MSVC compiled binary, you can find that it is actually passing the class pointer first, then the return value pointer. Which definitely doesn't match the absolute "the caller must allocate memory for the return value and pass a pointer to it as the first argument" statement from their own docs.
Prior discussion about this at https://news.ycombinator.com/item?id=29613640