4 ms·

Hmm... https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention https://docs.microsoft.com/en-us/cpp/build/x64-calling-conve... > Return values > A

Hmm... https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention https://docs.microsoft.com/en-us/cpp/build/x64-calling-conve... > Return values > A scalar return value that can fit into 64 bits, including the __m64 type, is returned through RAX. Non-scalar types including floats, doubles, and vector types such as __m128, __m128i, __m128d are returned in XMM0. The state of unused bits in the value returned in RAX or XMM0 is undefined. > User-defined types can be returned by value from global functions and static member functions. To return a user-defined type by value in RAX, it must have a length of 1, 2, 4, 8, 16, 32, or 64 bits. It must also have no user-defined constructor, destructor, or copy assignment operator. It can have no private or protected non-static data members, and no non-static data members of reference type. It can't have base classes or virtual functions. And, it can only have data members that also meet these requirements. (This definition is essentially the same as a C++03 POD type. Because the definition has changed in the C++11 standard, we don't recommend using std::is_pod for this test.) Otherwise, 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. Isn't this what https://github.com/ziglang/zig/issues/9998#issuecomment-997088467 https://github.com/ziglang/zig/issues/9998#issuecomment-9970... claims to be undocumented?

anonymfus 5y ago
Following comments on Github also point this out.
Andoryuuta 5y ago
> Otherwise, 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. I think the issue is that it isnt _fully_ documented anywhere. The MS docs do partially describe it, but it omits details about how this should be handled in the case of C++ member functions (which are the COM methods in question). C++ member functions always receive the hidden 'this' pointer as the first argument in Microsoft's x64 calling convention, which directly conflicts with this document stating the returned struct would be a "pointer to it as the first argument". You can see this in some of the godbolt links in the linked issue. Ultimately, some COM functions that take no arguments actually end up taking two hidden parameters in rcx and rdx (this pointer, and the return struct pointer respectively)

anonymfus 5y ago

Following comments on Github also point this out.

Andoryuuta 5y ago

> Otherwise, 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. I think the issue is that it isnt _fully_ documented anywhere. The MS docs do partially describe it, but it omits details about how this should be handled in the case of C++ member functions (which are the COM methods in question). C++ member functions always receive the hidden 'this' pointer as the first argument in Microsoft's x64 calling convention, which directly conflicts with this document stating the returned struct would be a "pointer to it as the first argument". You can see this in some of the godbolt links in the linked issue. Ultimately, some COM functions that take no arguments actually end up taking two hidden parameters in rcx and rdx (this pointer, and the return struct pointer respectively)