[Trivial] OS X: Make core.stdc.stdint independent of D long C++-mangling

[kinke]

C++ int64_t is defined as long long on both 32/64-bit OS X, so use the appropriate alias defined in core.stdc.config.

[dlang-bot]

Thanks for your pull request and interest in making D better, @kinke! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + druntime#2191"

[schveiguy]

It looks reasonable. Is there a way to know that it's correct? There are no unittests for this kind of stuff it seems.

[kinke]

There are DMD mangling interop tests (or at least will be); I'm about to create a DMD PR reverting to the previous mangling for long on 64-bit OS X; this is a prerequisite to get it working.

[schveiguy]

I have a mac, is there something I can compile to ensure this is correct?

[kinke]

For testing, you could compile

import core.stdc.stdint;
extern(C++) void fooCpp(int64_t, uint64_t);
void main() { foo(123, 456); }

(with DMD master) and check the function mangle. It should be __Z6fooCpplm according to https://godbolt.org/g/iaqA2y - edit: that seems to be wrong (wrong headers for cross-compilation?), it should be __Z6fooCppxy AFAIK, so maybe try compiling C++ and linking then to be safe.

[schveiguy]

I'm confused -- I wrote the following C++ file:

#include <stdint.h>

void fooCpp(int64_t, uint64_t)
{
}

And it mangles as __Z6fooCppxy

If I write your code (changing foo to fooCpp of course), it links fine against the C++ object on the 2.080 compiler (without your changes).

I don't know what the plan is here, but it seems like we shouldn't be ultimately changing the mangling at all, no?

[kinke]

So it's working (and this stuff is in LDC 1.10). ;) - This tiny PR here doesn't change the mangling, it just prepares for a D long mangled as C++ long again without breaking core.stdc.stdint.int64_t and friends. It's just a more robust way of defining them as C++ long long on Mac.

[schveiguy]

Sorry, wish I could have helped better, but my understanding of the OSX mangling issues is not good...