128bit types on Windows

Using Swift
, ,
1

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)

2

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.

Apparently @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.

3

https://reviews.llvm.org/D121497

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.

4

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.