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

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

[james woodyatt]

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

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

[Xavier Leroy]

> 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 understand your irritation about the current interface, and agree
that additional functions over the inet_addr abstract type are needed,
e.g. conversions to and from arrays of integers (each integer
representing one byte of the address).

But: I'm *extremely* wary about interfaces that assume that an inet_addr
is isomorphic to a 32-bit integer or to 4 octets, because these break
horribly with IPv6 addresses.  We've been hearing for so long that
IPv6 is the wave of the future that we might just as well be ready for IPv6.

- Xavier Leroy
-------------------
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

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

[james woodyatt]

On Thursday, November 15, 2001, at 01:48 , Xavier Leroy wrote:
>
> But: I'm *extremely* wary about interfaces that assume that an inet_addr
> is isomorphic to a 32-bit integer or to 4 octets, because these break
> horribly with IPv6 addresses.  We've been hearing for so long that
> IPv6 is the wave of the future that we might just as well be ready for 
> IPv6.

I received another response that raised this same issue.

It's nice to know that the abstract Unix.inet_addr type is intended to 
represent both IPv4 and IPv6 addresses.  The current conversions to and 
from strings just deal with dot quads and don't seem to understand 
textual representations of IPv6 addresses yet, but I guess I can see the 
roadmap now.

Consider this:

	val inet_addr_of_octets: string -> inet_addr
	val octets_of_inet_addr: inet_addr -> string

If inet_addr_of_octets is applied to a string that isn't four or eight 
octets in length, then it can raise Invalid_arg.


--
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

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

[Francois Rouaix]

Back in 1996/1997, Francis Dupont (Francis.Dupont@inria.fr) was working
on IPv6, and he patched the conversion functions to work with IPv6
addresses (and probably some other stuff from unix.ml/libunix) . IIRC,
he then got MMM (the web browser) to run on IPv6 enabled machines by
simply recompiling it (no source changes in the app).
I guess that this proved that you can get any OCaml application IPv6
enabled if you do the appropriate work in libunix. Maybe Francis still
has a copy of that code BTW.

HTH,
--f
François Rouaix


-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of james woodyatt
Sent: Thursday, November 15, 2001 12:14 PM
To: Xavier Leroy
Cc: The Trade
Subject: Re: [Caml-list] parsing and emitting Unix.inet_addr values

On Thursday, November 15, 2001, at 01:48 , Xavier Leroy wrote:
>
> But: I'm *extremely* wary about interfaces that assume that an
inet_addr
> is isomorphic to a 32-bit integer or to 4 octets, because these break
> horribly with IPv6 addresses.  We've been hearing for so long that
> IPv6 is the wave of the future that we might just as well be ready for

> IPv6.

I received another response that raised this same issue.

It's nice to know that the abstract Unix.inet_addr type is intended to 
represent both IPv4 and IPv6 addresses.  The current conversions to and 
from strings just deal with dot quads and don't seem to understand 
textual representations of IPv6 addresses yet, but I guess I can see the

roadmap now.

Consider this:

	val inet_addr_of_octets: string -> inet_addr
	val octets_of_inet_addr: inet_addr -> string

If inet_addr_of_octets is applied to a string that isn't four or eight 
octets in length, then it can raise Invalid_arg.


--
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
-------------------
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

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

[james woodyatt]

On Thursday, November 15, 2001, at 12:30 , Francois Rouaix wrote:
>
> I guess that this proved that you can get any OCaml application IPv6
> enabled if you do the appropriate work in libunix. Maybe Francis still
> has a copy of that code BTW.

I had a conversation a couple days ago with a co-worker who is active in 
several IETF activities, and we were commiserating about the sorry state 
of industry efforts to transition away from IPv4 to IPv6.  I've almost 
convinced myself that it will never happen.  He's not nearly so 
pessimistic as me.

We agreed that one of things holding back development of IPv6 
applications are the crufty interfaces that C language programmers have 
as a result of extending the BSD sockets API in the way they did.

I'm very encouraged to see the Caml team taking appropriate steps to 
avoid that pitfall.  Very encouraged.  I had been planning to leave open 
support for AAAA or A6 resource records (whichever emerges as the 
standard) in my stub resolver, and now I have a better reason for doing 
the extra work.


--
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