caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: cedilla+ocaml@gmail.com
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] UDP broadcast from Windows
Date: Wed, 10 Oct 2007 10:55:17 +0200	[thread overview]
Message-ID: <470C9375.70807@inria.fr> (raw)
In-Reply-To: <470C2B72.3090704@gmail.com>

Reed Wilson wrote:
> Hi guys!
>
> I'm in the middle of writing a program which does a UDP broadcast, but I
> noticed it doesn't work on Windows. Here's the source:
>
> try (
>   let sock = Unix.socket Unix.PF_INET Unix.SOCK_DGRAM 0 in
>   Unix.setsockopt sock Unix.SO_BROADCAST true;
>   let sent = Unix.sendto sock "ping" 0 4 [] (Unix.ADDR_INET
> ((Unix.inet_addr_of_string "255.255.255.255"), 12345)) in
>   Printf.printf "Sent %d\n" sent;
> ) with
>   | Unix.Unix_error (x,y,z) -> Printf.printf "%S - %s,%s\n"
> (Unix.error_message x) y z
> ;;
> I looked around in the OCaml source, and it
> looks like the broadcast address is specifically disallowed unless
> HAS_INET_ATON is defined? Why is this?

Quoting the Linux man page:

  The  inet_addr()  function  converts  the Internet host address cp from
  numbers-and-dots notation into binary data in network byte  order.   If
  the input is invalid, INADDR_NONE (usually -1) is returned.  This is an
  obsolete interface to inet_aton(), described immediately above;  it  is
  obsolete   because   -1  is  a  valid  address  (255.255.255.255),  and
  inet_aton() provides a cleaner way to indicate error return.

Unfortunately, Windows does not provide any of the better substitutes
for inet_addr, namely inet_aton and inet_pton.  Send a bug report to
Microsoft.

> I noticed that when I force the address by replacing:
> Unix.inet_addr_of_string "255.255.255.255"
>
> with:
> Obj.magic "\255\255\255\255"
>
> it _seems_ to work fine. [...]
> And am I breaking anything by using magic?

Currently not.  Inet addresses are represented internally as strings
(of length 4 for IPv4, 16 for IPv6) containing the bytes of the
address in network byte order.  This is of course not guaranteed but
unlikely to change soon.

- Xavier Leroy


      reply	other threads:[~2007-10-10  8:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-10  1:31 Reed Wilson
2007-10-10  8:55 ` Xavier Leroy [this message]

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=470C9375.70807@inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@yquem.inria.fr \
    --cc=cedilla+ocaml@gmail.com \
    /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).