UDP+binary+passive and prim_inet:recvfrom/3 bug?

Samuel Tardieu sam@REDACTED
Fri Jan 5 20:00:51 CET 2001

I wonder if this code in prim_inet is correct when using an UDP socket in
passive and binary modes:

recvfrom0(S, Length, Time) when port(S), integer(Length), Length >= 0 ->
    case ctl_cmd(S, ?UDP_REQ_RECV,[enc_time(Time),?int32(Length)]) of
        {ok,[R1,R0]} ->
            Ref = ?u16(R1,R0),
                {inet_async, S, Ref, {ok, [F,P1,P0 | AddrData]}} ->
                    {IP,Data} = get_ip(F, AddrData),
                    {ok, {IP, ?u16(P1,P0), Data}};
                {inet_async, S, Ref, Status} ->
        Error ->

If the UDP socket has the "binary" option set, then I think that the
message that is received by the receive statement looks like

   {inet_async, S, Ref, {ok, <<F,P1,P0, AddrData/binary>>}}

which is covered by the default case instead of being covered explicitely,
as the result of recvfrom0/3 does not hold the expected {ok, {IP, Port, Data}}.
Of course, get_ip4/1 and get_ip6/1 (both called by get_ip/2) need a "binary"
alternative too.


More information about the erlang-questions mailing list