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),
receive
{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} ->
Status
end;
Error ->
Error
end.
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.
Sam
More information about the erlang-questions
mailing list