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

use Bytes.t as data type for IPv6 addresses #115

Merged
merged 6 commits into from
Mar 13, 2023

Conversation

verbosemode
Copy link
Contributor

  • this PR is a proposal to addresses issue Use 16-byte string for internal representation of IPv6 addresses #16
  • I didn't touch any parsing functions, but migrated auxiliary functions to operate on Bytes. If this was over the top, I could cut this PR down to the essential parts and keep the rest for later.
  • I've resorted to imperative code due to the index based set functions of Bytes

@verbosemode
Copy link
Contributor Author

The current build failures are mainly due to unused functions in the B128 module. But maybe it is a good idea to keep them for future PRs.

@hannesm
Copy link
Member

hannesm commented Mar 12, 2023

I like the code changes, thanks a lot! :)

I pushed a commit which removes some unused bindings -- if we need them at a later point, we can add them then :) -- this should make the CI green.

Does this code fix #113 as a side-effect? Would be great to have it double-checked by @RyanGibb, and maybe have a test case?

RyanGibb added a commit to RyanGibb/eon that referenced this pull request Mar 13, 2023
@RyanGibb
Copy link
Contributor

I can confirm that this fixed #113. Thanks @verbosemode !

@hannesm
Copy link
Member

hannesm commented Mar 13, 2023

@RyanGibb cool, great. Could you PR a test case for that issue you uncovered?

@hannesm
Copy link
Member

hannesm commented Mar 13, 2023

@RyanGibb cool, great. Could you PR a test case for that issue you uncovered?

Sorry for the noise, while at this PR, I pushed 5c4a09b as a test for your observed failure. This fails on the main branch, and succeeds on this branch.

I'd move on to merge this PR (today or tomorrow) and cut a release, what do others think? @RyanGibb @avsm

@RyanGibb
Copy link
Contributor

Apparently at the exact same minute as you commented I also opened a pr https://github.com/mirage/ocaml-ipaddr/pull/116/files 😄 I'm happy to go with your test though. The only thing is perhaps it would be better to use the address 0:0:8000:0:0:0:0:0 as it's the simplest address that exhibits the problematic behavior, and because 2a01:4f9:c011:87ad:0:0:0:0 is actually the address of my own server.

@hannesm
Copy link
Member

hannesm commented Mar 13, 2023

@RyanGibb I added the 0:0:800:: test case as well.

@RyanGibb
Copy link
Contributor

@RyanGibb I added the 0:0:800:: test case as well.

Thanks!

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.

3 participants