caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: max630@mail.ru
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Unix.file_descr -> int ???
Date: Wed, 12 Jun 2002 09:10:37 +0900	[thread overview]
Message-ID: <20020612091037I.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <20020612022611.B680@max.home>

From: Max Kirillov <max630@mail.ru>

> I was trying to trace a code with some significant amount of
> select'ed fds. At some point, I faced the fact that I just
> have no way to "show" a descriptor value. That was a real
> shock. At the moment, the bug is found and fixed
> deductively, but the question remains.

If your goal is debugging, then you can dump the value in this way.
Note that this is safe (we check the data representation before
dumping), but system dependent.

Unix version:

let dump_fd (h : Unix.file_descr) =
  let obj = Obj.repr h in
  if Obj.is_int h then string_of_int (Obj.obj obj)
  else invalid_arg "dump_fd"

Windows version:

let dump_handle (h : Unix.file_descr) =
  let obj = Obj.repr h in
  if Obj.is_block obj && Obj.tag obj = Obj.custom_tag then
    Nativeint.format "%x" (Obj.obj obj)
  else invalid_arg "dump_handle"

> I know almost nothing about win32, but I was very surprised
> to discover that win32 has functions, isomorphic to
> low-level unix calls. However, I suspect (I don't have win32
> headers to look in just now) that HANDLE is again a
> "typedef" of intteger.

As you can see, win32 fd's have to be handled differently.
One reason is that caml fits both HANDLE and SOCKET in the same
abstract datatype.  But even HANDLE is not an int, it is a long, and
you cannot be sure it would fit in an ocaml int, so you would need a
nativeint anyway.

> Anyway, any meaningful type barrier is good. Maybe the
> discussed too. But, since we all know that file_descr and
> dir_handle are integers, could it be worthwhile to have
> functions *_of_int and int_of_*?

If it's okay to be unix specific, then something like that could do
the job.
let file_descr_of_int n =
  let fd : Unix.file_descr = Obj.magic (n : int) in
  try Unix.close (Unix.dup fd); fd
  with _ -> invalid_arg "file_descr_of_int"

However, I would not take any responsibility for problems with this
code.

On windows it's more painful. For this kind of use it might be more
reasonable to use a windows specific library, as not all notions can
be mapped to unix ones.

        Jacques Garrigue

P.S. The above uses of Obj.obj and Obj.magic are in some way legal, as
they are just breaking an abstraction barrier. But any error in the
code can still get you a segmentation fault...
-------------------
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/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  parent reply	other threads:[~2002-06-12  0:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-11 14:31 Max Kirillov
2002-06-11 15:40 ` Bruno.Verlyck
2002-06-11 15:45 ` Xavier Leroy
2002-06-11 19:26   ` Max Kirillov
2002-06-11 23:12     ` Berke Durak
2002-06-12  0:10     ` Jacques Garrigue [this message]
2002-06-12  7:49     ` Ocaml debugging (Was [Caml-list] Unix.file_descr -> int ???) Mattias Waldau
2002-06-12 11:17       ` Pixel
2002-06-12  8:08     ` [Caml-list] Unix.file_descr -> int ??? Xavier Leroy
2002-06-12  7:42   ` Basile STARYNKEVITCH
2002-06-12  8:21     ` Xavier Leroy
2002-06-12 16:06       ` Max Kirillov
2002-06-13 10:24       ` Jean-Marc Eber
2002-06-12 13:09     ` Bruno.Verlyck
2002-06-12 15:44   ` John Max Skaller
2002-06-12  9:53 Damien Doligez
2002-06-12  9:57 ` Jacques Garrigue
2002-06-12 11:04   ` Jacques Garrigue
2002-06-18 13:38 Alessandro Baretta
     [not found] ` <000101c21705$d9f23640$0501a8c0@lexifi01>
2002-06-18 22:41   ` Alessandro Baretta
2002-06-19 16:22     ` John Max Skaller
2002-06-20 11:23     ` Xavier Leroy
2002-06-20 11:52       ` Markus Mottl
2002-06-20 13:14       ` Alessandro Baretta
2002-06-20 13:23         ` Stefano Lanzavecchia
2002-06-20 16:22           ` Alessandro Baretta
2002-06-20 14:42         ` YAMAGATA yoriyuki
2002-06-20 12:24 Ohad Rodeh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020612091037I.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=max630@mail.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).