Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement NativeCall wide string support #1137

Open
wants to merge 46 commits into
base: main
Choose a base branch
from

Conversation

Kaiepi
Copy link
Contributor

@Kaiepi Kaiepi commented Jul 11, 2019

See the Rakudo pullreq for info on what this does

Kaiepi added 30 commits July 7, 2019 01:17
It's ridiculous to try to work them out entirely via macros since
they differ depending on platform, architecture, and compiler all at
once, so use a compiler probe instead.
This uses no more memory than before on 64 bit systems and is required
to implement wide string support.
Required before wide string support can be implemented.
It'd help if the code specific to Windows would actually get used.
Originally I was planning on passing the length of strings to the CStr
REPR using it, but it's impossible to know before the type is composed.
Before, they were being cast to UTF-8 strings, which breaks wide/u16/u32
strings in the process.
@Kaiepi
Copy link
Contributor Author

Kaiepi commented Jul 11, 2019

Looks like AppVeyor is unhappy with my use of stringapiset.h, which isn't available before Vista... I'll need to find some other way to transcode wide strings to UTF-8 since Windows didn't support it as a locale rather than just a code page until very recently. Since Windows wide strings are UTF-16, I'll probably have to make some changes to src/strings/utf16.c to support transcoding strings of types other than MVMString and char *.

Edit: I didn't need to lol

src/strings/wide.c Outdated Show resolved Hide resolved
@Kaiepi Kaiepi force-pushed the nativecall-unicode branch 2 times, most recently from 3869964 to f39103b Compare July 11, 2019 16:59
@patrickbkr
Copy link
Member

Is there a reason why this isn't merged yet? Do the core devs need a poke?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants