From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 130C67FA13 for ; Fri, 11 Jul 2014 10:03:13 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of raphlalou@gmail.com) identity=pra; client-ip=209.85.192.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="raphlalou@gmail.com"; x-sender="raphlalou@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of raphlalou@gmail.com designates 209.85.192.44 as permitted sender) identity=mailfrom; client-ip=209.85.192.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="raphlalou@gmail.com"; x-sender="raphlalou@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qg0-f44.google.com) identity=helo; client-ip=209.85.192.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="raphlalou@gmail.com"; x-sender="postmaster@mail-qg0-f44.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQAAFGZv1PRVcAsm2dsb2JhbABZg2BagnG+AYdCAYEDCBYPAQEBAQEGCwsJFCiEAwEBAQMBEhEdARsdAQMMBgULDQICJgICIgERAQUBHAYTIogLAQMJCA2hSGqLJ4FygxCMEwoZJw1khjQRAQUOgR6NWEIHgneBTAWbBYFKkGAYKYR1PIEz X-IPAS-Result: AvQAAFGZv1PRVcAsm2dsb2JhbABZg2BagnG+AYdCAYEDCBYPAQEBAQEGCwsJFCiEAwEBAQMBEhEdARsdAQMMBgULDQICJgICIgERAQUBHAYTIogLAQMJCA2hSGqLJ4FygxCMEwoZJw1khjQRAQUOgR6NWEIHgneBTAWbBYFKkGAYKYR1PIEz X-IronPort-AV: E=Sophos;i="5.01,642,1400018400"; d="scan'208";a="84736707" Received: from mail-qg0-f44.google.com ([209.85.192.44]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Jul 2014 10:03:12 +0200 Received: by mail-qg0-f44.google.com with SMTP id j107so647665qga.17 for ; Fri, 11 Jul 2014 01:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+RqWWJhtgKfr21oUGWeWHv7MFjBVvK9y4KeBLO1dYI4=; b=I448nyLGZSaeTDcYIyn/NAC8sTWOOs/4RNOYmp8/2gcoI7jxzs+rbLiWEMQGmKiOvM Vzuhu+i5RWOB51jfyk9xVL3B5ddhl4z87/DSRxGQiEcjSIH2CbAnk48vVVwWo39DF05P xnKt0vgwUfHywvYo2S3BtQysJmUNX9lINLwtsNwiUUGE4bklXi6QOrosz9wMWFvf/j90 aB4SBGFgjVXshDHoNTStkxHobl+jROoZsSg7u/w0UpsTi3XPp5g4JEO+U/wpCoMSpZ30 uzY20oY9LDqw8oFE2CFl7hg1clacnrvJ44Mg3EM617YEhfq/hfOAa8KTc31Obpt5pBM5 Fx6Q== MIME-Version: 1.0 X-Received: by 10.224.223.135 with SMTP id ik7mr89834365qab.26.1405065791317; Fri, 11 Jul 2014 01:03:11 -0700 (PDT) Received: by 10.96.187.1 with HTTP; Fri, 11 Jul 2014 01:03:11 -0700 (PDT) In-Reply-To: <53BD7D68.1090409@luminar.eu.org> References: <53BD7D68.1090409@luminar.eu.org> Date: Fri, 11 Jul 2014 09:03:11 +0100 Message-ID: From: =?UTF-8?Q?Rapha=C3=ABl_Proust?= To: "Vincent B." Cc: OCaml Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] IPv6 zone-id On Wed, Jul 9, 2014 at 6:35 PM, Vincent B. wrote: > The Unix module does not make possible to use IPv6 link-local > addresses. > > This is due to the fact that the "sockaddr" type in Unix is not as > complete as its C counterpart, especially it lacks zone-id information > that is required to use such addresses. > > Since I needed such features, I started writing a library > (http://github.com/vbmithr/ocaml-sockopt), unfortunately, given that > every networking piece of code written in OCaml use the primitives of > the Unix module, I would have to patch all networking code I want to > use which is not very convenient. Is it possible to make a new networking module using Cstruct to manage sockaddr and such? > > So I'm in the process of writing a patch for OCaml and I'm taking the > approach of extending the sockaddr type like this: > > type sockaddr_raw (* a real struct sockaddr *) > > type sockaddr =3D > ADDR_UNIX of string > | ADDR_INET of inet_addr * int > | ADDR_RAW of sockaddr_raw > > And then upgrading all the Unix code that uses type sockaddr. > > This approach seems to me the most conservative towards existing > code. Should I continue in this direction or this design is not the > optimal one ? Although very conservative towards the existing codebases, I don't like this approach for the following reasons. The same sockaddr can be represented in different ways (which means that equality becomes non-trivial, and the choice of representation is non-obvious for programmers). The Unix module is build as abstractions from the underlying system, adding a sockaddr_raw defeats that. It becomes abstractionless. Additionally, is sockaddr_raw completely opaque? what constructors/destructors are available? Cheers, --=20 ______________ Rapha=C3=ABl Proust