On Wed, Oct 14, 2009 at 02:07:15PM +0100, Daniel P. Berrange wrote:
On Wed, Oct 14, 2009 at 02:31:29PM +0200, Daniel Veillard wrote:
On Wed, Oct 14, 2009 at 12:33:36PM +0100, Daniel P. Berrange wrote:
It would be nice to have this in a callable function too
int virSocketAddrRange(struct sockaddr_storage *start, struct sockaddr_storage *end);
Are you supposed to look struct sockaddr_storage ? As posted in my last mail this seems a completely opaque structure at least in theory and if you want to keep the portability it's supposed to bring.
You cast to one of the address specific structs according to the ss_family field.
humpf ... okay it has to be cast to be accessed, that's weird, definitely.
Yeah, ideally it would have been in a union, but POSIX the way it was defined when sockets API were first designed, didn't allow a union to be retrofitted.
We could consider a union ourselves though for our API if it might make it a little clearer, eg
typedef union { struct sockaddr_storage stor; struct sockaddr_in inet4; struct sockaddr_in6 inet6; } virSocketAddr;
to allow more direct access without the casting
Ah, yes, that look way better that way, and use that for all our internal APIs. Fine then, I will look at this, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/