posix stdlib, inttypes - compatibility with new wchar_t

[WalterBright]

No description provided.

[dlang-bot]

Thanks for your pull request, @WalterBright!

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#2394"

[CyberShadow]

These are pretty terrible.

It's even worse thinking that D users will need to do the same for similar code in their local bindings.

[n8sh]

Does this cause problems for LDC2 or can this just be merged?

[ibuclaw]

Static if would be better, making sure that wchar_t is a distinct type, and not an alias.

[rainers]

FWIW: I agree with most that these changes are pretty bad, the cure seems worse than the disease (AFAICT mangling of C++ functions that happen to use wchar_t, too). I think we should further explore a way to define aliases that only affect C++ mangling of the symbol, but not the function type, as if pragma(mangle) is being used.

[jacob-carlborg]

I think we should further explore a way to define aliases that only affect C++ mangling of the symbol, but not the function type, as if pragma(mangle) is being used.

dlang/dmd#7458

My conclusion of that PR:

The issue is, as Rainer pointed out, that the mangling is used for type comparison as well. An alias with pragma(mangle) is not intended to introduce a new type.

[rainers]

dlang/dmd#7458

Maybe your PR can work if it is only applied to C++ symbol mangling. Type comparison happens for D mangling. It should probably use another pragma then.

[jacob-carlborg]

Maybe your PR can work if it is only applied to C++ symbol mangling. Type comparison happens for D mangling. It should probably use another pragma then.

Possibly.

[RazvanN7]

Closing as per @rainers comment and lack of activity.