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

IP iteration overflows #5

Open
jwilner opened this issue Aug 12, 2020 · 5 comments
Open

IP iteration overflows #5

jwilner opened this issue Aug 12, 2020 · 5 comments

Comments

@jwilner
Copy link
Contributor

jwilner commented Aug 12, 2020

We need tests verifying that the v4/v6 logic behaves appropriately when hitting mins or maxes for their types. That probably looks like a) deciding what is appropriate, b) writing tests and c) making those tests pass.

@cbertinato
Copy link
Contributor

cbertinato commented Aug 16, 2020

With regard to a): I think it would be useful to signal when reaching the "end", whether it's iterating from above or below. Like python's StopIteration. I can foresee a case where one might want to iterate over a range then move on after the range is exhausted. No proposed implementation yet, just voicing the idea.

@jwilner
Copy link
Contributor Author

jwilner commented Aug 16, 2020

@cbertinato isn't that what we achieve already?

iter := ipx.IterIPs(net.ParseIP("0.0.0.0"), 1, nil)
for iter.Next() {
}
// you've reached end, last must've been 255.255.255.255

@cbertinato
Copy link
Contributor

Ah yeah. Derp. I spoke without trying. My bad.

@jwilner
Copy link
Contributor Author

jwilner commented Aug 16, 2020

Haha no worries. I think there is some slight ambiguity as the loop could also immediately return false because of illegal arguments (e.g. step that will never reach end), but I basically think it's acceptable.

@jwilner
Copy link
Contributor Author

jwilner commented Aug 16, 2020

In general, because the only errors you can encounter with this are blatant programmer mistakes (e.g. nil pointers, steps that never hit their target), I've avoided returning errors. Exposing the errors would mean that programmers would have to worry about checking errors in the common case when all that's happening under the covers is math and there's no risk of failure.

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

No branches or pull requests

2 participants