From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id EAA26340; Thu, 15 Nov 2001 04:53:47 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA26289 for ; Thu, 15 Nov 2001 04:53:43 +0100 (MET) Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.89]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fAF3rfX17307 for ; Thu, 15 Nov 2001 04:53:41 +0100 (MET) Received: from smtp-relay01.mac.com (server-source-si02 [10.13.10.6]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id fAF3aOsD002924 for ; Wed, 14 Nov 2001 19:36:24 -0800 (PST) Received: from asmtp02.mac.com ([10.13.10.66]) by smtp-relay01.mac.com (Netscape Messaging Server 4.15 relay01 Jun 21 2001 23:53:48) with ESMTP id GMTPHB00.2DS for ; Wed, 14 Nov 2001 19:53:35 -0800 Received: from kallisti.apple.com ([17.206.25.144]) by asmtp02.mac.com (Netscape Messaging Server 4.15 asmtp02 Jun 21 2001 23:53:48) with ESMTP id GMTPHB00.0CG for ; Wed, 14 Nov 2001 19:53:35 -0800 Date: Wed, 14 Nov 2001 19:53:36 -0800 Reply-To: jhw@wetware.com Subject: [Caml-list] parsing and emitting Unix.inet_addr values Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) From: james woodyatt To: The Trade Content-Transfer-Encoding: 7bit Message-Id: <58BE67E6-D97C-11D5-BA32-000502DB38F5@mac.com> X-Mailer: Apple Mail (2.472) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 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 wrappers instead? Any advice from the Caml team would be appreciated. -- j h woodyatt "...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