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

add support for varying width null terminator for (get/put)ZeroTerminatedByteArray() #112

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

demon36
Copy link

@demon36 demon36 commented Aug 30, 2021

related to jnr/jnr-ffi#30

@headius
Copy link
Member

headius commented Aug 31, 2021

Quick comment: Please do PRs using your own branches, rather than using your copies of existing branches. I guess the idea is that existing branches, and especially master, should never have unapproved commits to avoid confusion across forks.

https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request

@headius headius added this to the 2.0 milestone Aug 31, 2021
@headius
Copy link
Member

headius commented Aug 31, 2021

Marking for 2.0 as I think that will be the logical leap forward with the native binary. We will build in fallbacks to old behavior when the binary has not been updated, and build for as many platforms as possible whenever it changes, but we need to be able to move the native bits forward.

@demon36
Copy link
Author

demon36 commented Sep 1, 2021

anything to be done from my side ?

@headius
Copy link
Member

headius commented Apr 4, 2022

I was pinged today by @demon36 and would like to revisit this.

The problem then, as it is now, is making this change when we do not have access to all native platforms to easily rebuild the jffi stub. If we can do this in an incremental way, falling back on old logic when the binary for a given platform has not been rebuilt, it would mean we can start supporting this feature on at least some platforms.

The alternative is to fix the build/platform support problem and get automated builds of as many platforms as possible with other platforms awaiting assistance from the community.

@headius
Copy link
Member

headius commented Apr 28, 2022

This is still in the pipeline and we are getting closer to having an automated setup to build all these binaries. However, we have been swamped with other work and may not get back to this for a few weeks.

@headius
Copy link
Member

headius commented Apr 28, 2022

See #124 for ongoing work to tie up the loose ends of the existing qemu native builds.

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

2 participants