urlapi: parse IPv6 literals without ENABLE_IPV6 #10660
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
As per the discussion on the curl-library mailing list, here is a patch to allow URLs with IPv6 literals to be parsed correctly even when
ENABLE_IPV6
is not configured, including when the target lacks theAF_INET6
constant (and other IPv6 definitions).It simply enables the existing curl IPv6 literal parsing capabilities when
ENABLE_IPV6
is not defined, and creates a limited-scope definition ofAF_INET6
that the URL and IP parsing code (only) use to communicate. It seemed safer to not defineAF_INET6
more widely, and it seemed unnecessarily complex to switch curl to define its own constant and use it, so I took a simple pragmatic approach. Feedback on this detail, including the resulting redefinition ofAF_INET6
in a three spots, is welcome.For tests, I simply relaxed the restrictions on the existing tests to now require IPv6 support. I do not know if any CI runs the tests this way (but I did manually).
I don't have a machine that lacks
AF_INET6
, so I also simulated that case by undefining it.All tests passed for me on Linux x86_64.