From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p72GwZw1020137
	for <caml-list@sympa-roc.inria.fr>; Tue, 2 Aug 2011 18:58:35 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al8DAA8sOE7RVdIyjWdsb2JhbAAoGqddCBQBAQEBCQkLCRIGIYFAAQEBAQMSAiwBGx0BAwwGBQsDOCIBEQEFAQ4BDQYTGgiHTiOiKQqML4JUhQ87iG0CAwaGPASHWoshiDOEGTyDeg
X-IronPort-AV: E=Sophos;i="4.67,307,1309730400"; 
   d="scan'208";a="114789236"
Received: from mail-pz0-f50.google.com ([209.85.210.50])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 02 Aug 2011 18:58:29 +0200
Received: by pzk2 with SMTP id 2so14513121pzk.37
        for <caml-list@inria.fr>; Tue, 02 Aug 2011 09:58:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        bh=acHGm0zEixRZCP2665QsvQrKKpRhA5UJ1pX6yvwN2Jk=;
        b=VFFv6NX5HjWZw59FXoUfG8WenfU20pjBRYk/td7QhGXJuiBc59FHT00A0LRljWmdKd
         jabB18n/prj3BpF2PwWLoY6p4H7uxf3WV4iuK61V5C4AvxPHHqFf2z6sgW1s6HbMudNq
         F+iQJMmSynVucsVow2W6C2g92sy92UEOCOjuE=
MIME-Version: 1.0
Received: by 10.68.47.201 with SMTP id f9mr64883pbn.242.1312304306720; Tue, 02
 Aug 2011 09:58:26 -0700 (PDT)
Received: by 10.68.43.66 with HTTP; Tue, 2 Aug 2011 09:58:26 -0700 (PDT)
In-Reply-To: <000001cc5134$d990da80$8cb28f80$@metastack.com>
References: <000001cc5134$d990da80$8cb28f80$@metastack.com>
Date: Tue, 2 Aug 2011 11:58:26 -0500
Message-ID: <CABWZ6ORyKUMRaU18WsFGC=UejP-5uh3d6BK72hChR7Psu2wtNA@mail.gmail.com>
From: Romain Beauxis <romain.beauxis@gmail.com>
To: David Allsopp <dra-news@metastack.com>
Cc: OCaml List <caml-list@inria.fr>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p72GwZw1020137
Subject: Re: [Caml-list] Unix.file_descr and unixsupport.h

Hi!

2011/8/2 David Allsopp <dra-news@metastack.com>:
> OK, some further digging into my problem with ocaml-ssl eventually revealed
> that the problem is the way it handles Unix.file_descr. On Unix, this is
> just an [int] and so ocaml-ssl's stubs treat it as such. Under Windows, it's
> a custom block as file_descr is a C struct containing a lot of information.
>
> unixsupport.h is installed with the other caml headers, although it's not
> referenced by any of them and as far as I can tell isn't referred to in the
> manual. For Unix implementations of OCaml, it's a pretty dull file but the
> Windows version contains a definition for Socket_val which will extract the
> underlying OS handle for a socket from a file_descr.
>
> I've therefore tried inserting #include <caml/unixsupport.h> and changing
> the offending portion of code in ocaml-ssl to this:
>
> #ifdef Socket_val
>  SOCKET socket = Socket_val(socket_);
> #else
>  int socket = Int_val(socket_);
> #endif
>
> But my questions - is this "safe"? Is it likely to continue to work? If not,
> is there - or could there be - some kind of official way to extract file
> descriptors which aims to work in a cross-platform manner?

I think the safest for now is to condition your macros on the OS and
only address WIN32/Unix cases.

I have submitted a bug upstream about this:
  http://caml.inria.fr/mantis/view.php?id=5249

Romain