Re: [libvirt] [PATCH] Fixed URI parsing
On 02/09/2012 06:53 PM, Laine Stump wrote:
The problems I can see with that:
1) That would require you to once again modify the server string
in-place, but you can't rely on it still having the 2 extra bytes, so
you would have to create a new string.
Modifying the server is not a problem. If you allocate new string it is
freed properly with xmlFreeURI(). I know it's a little bit clumsy but it
works. Also the modification is needed only for calling the function once.
2) If somebody decided in the future to use different libxml2 API on
the
URI (e.g. xmlPrintURI), or wrote their own code to do something with the
string, they would have to know to provide a wrapper for that as well.
Yes, this is a little problem at first. However, on the other hand, if
somebody wants to use the uri->server fro anything, they would have to
know to use the function returning proper hostname/ip.
3) Just the oddness of determining whether or not to add brackets
back
based on whether or not you find a ":" in the string.
This seems very reasonable to me. The brackets are there just for the
purpose of determining what is the IPv6 address and what's the port. It
is exactly the reason why it is needed :)
On the other hand, if you leave the brackets in, then everybody who
uses
uri->server directly needs to know that it may have extraneous brackets
around it, so I'm undecided. Maybe someone else has an opinion that will
take it over the edge.
There (maybe) is one more way how to do this. I'm saying "maybe"
because
while handling all the cons we discussed, it is also the worst option to
deal with such a problem, I guess.
We can create new structure (virURI with virURIPtr etc.) that
encapsulates xmlURI and also has it's own members that would help
determining what to do in what function. There would be one more layer
of functions accessing this structure and there could even be a pointer
to xmlURIPtr that one can use for unimplemented functions around the new
structure.
But as I say, I think this is the worst option considering the real
problem is with "brackets around IPv6 in libxml2" and fixing it there
would save us from dealing with lots of bugs.