[Caml-list] parsing and emitting Unix.inet_addr values

[james woodyatt <jhwoodyatt@mac.com>]

Okay, so I guess I have another item for the Unix library wish list...

I'm writing an asynchronous DNS stub resolver, and it irritates me to 
have to convert 4-octet IPv4 addresses in A records into dot-quad 
strings, just so I can then call Unix.inet_addr_of_string to get the 
address into the abstract type.  I'd much rather construct the 
Unix.inet_addr directly from the four octets, especially since I know 
that internally they are exactly the same representation.

I'd be happy to have the following pair of functions:

	val parse_inet_addr: char Stream.t -> inet_addr
	val emit_inet_addr: Buffer.t -> inet_addr -> unit

These would simplify things for me, and it's what I plan to write in the 
interim.  But maybe we need something else in the Unix library.

One approach is to wrap the C language <arpa/inet.h> functions with 
external proxy functions.  I'm not sure I like that idea, having seen a 
lot of code explode because integers in host order are only the same as 
integers in network order on big-endian CPU architectures.  IPv4 
addresses are represented as strings in only one format, but with 
integers there are two: network-ordered and host-ordered.

It might be tempting to define conversions to and from host-ordered 
int32 values, and forget about the network-ordered format:

	val inet_addr_of_int32: int32 -> inet_addr
	val int32_of_inet_addr: inet_addr -> int32

I could make a long, pointy-headed case against doing this.  The crux of 
my argument would be that it's safer to discourage programmers from 
storing network addresses in values with integer type.

I could do this:

	val inet_addr_of_tuple: char * char * char * char -> inet_addr
	val tuple_of_inet_addr: inet_addr -> char * char * char * char

Indeed, the first pair of functions in this message could easily be 
implemented in Caml if this last pair were the external C proxy 
functions.

If I make this patch, would anyone else care?  Would anyone on the Caml 
team at Inria be interested in reviewing it?  Am I the only one worried 
about problems posed by using integers to represent network addresses?  
Should I just implement the <arpa/inet.h> wrappers instead?

Any advice from the Caml team would be appreciated.


--
j h woodyatt <jhw@wetware.com>
"...the antidote to misinformation is more information, not less."
                                                      --vinton cerf

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr