I need to use C++ on Windows to do Audio without distributing a binary as there is no supported C API.
When trying to use WinSDK.DirectX.XAudio29 (XAudio.h) a shared header is imported containing 128 bit suffixes that Swift doesn't know how to handle.
C:\Program Files (x86)\Windows Kits\10\Include\10.0.20348.0\shared\intsafe.h:215:64: error: invalid suffix 'i128' on integer constant
#define INT128_MAX 170141183460469231731687303715884105727i128
C:\Program Files (x86)\Windows Kits\10\Include\10.0.20348.0\shared\intsafe.h:216:59: error: invalid suffix 'ui128' on integer constant
#define UINT128_MAX 0xffffffffffffffffffffffffffffffffui128
The header doesn't appear to have a macro to disable these.
I wasn't able to find any existing issues for this or anything from searching.
Is there a workaround for this?
compnerd.org Swift version 5.9-dev (LLVM 107de6a91bc1dbd, Swift 022311e438e7703)
May 16, 2023, 5:28pm
I don't think the issue is that Swift doesn't know how to handle them; Clang is the thing that handles C/C++ headers for us.
@scanon implemented support for the suffix as a Microsoft extension at one point, but it was removed because the Clang maintainers didn't think it was an actual extension.
What I meant is that I implemented rough literal support a decade ago (piggybacking on ms-extensions, where someone had defined the suffixes without an implementation), which led to a bunch of discussion and ultimately this post by Richard Smith...
May 16, 2023, 5:31pm
I've not had time to go back around and try to figure out what the reviewers are looking for, but wouldn't mind someone else digging into the modules behaviour to get that resolved.
Yup, that makes sense. I updated the post and removed the wrong tags.
It sounds like the reviewers just want to make sure it's supposed to be expanded, since it doesn't appear they are referenced anywhere in the SDK.
I notice that there is another instance several lines above the two that are erroring.
So I did a test and changed the 2 with errors to valid Ints.
#define INT128_MIN (-170141183460469231731687303715884105727i128 - 1)
#define INT128_MAX 1
#define UINT128_MAX 0xf
The one several lines above never causes an error. So I don't think it's going to be a module problem.
Though at the end of the build I do get cxx-interop shim errors, so it wasn't technically a successful build.
I'll drop the sdk into Finder tomorrow and let it index everything and do a deeper search.
Something must be expanding them, and it sounds like that's the proof the reviewers want to see.