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

[Tony Rogvall]

Samuel Tardieu wrote:

> 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

>From inet_drv.c

/*
** passive mode reply:
**        {inet_async, S, Ref, {ok,[H1,...Hsz | Data]}}
*/

This means that the inet_drv ADDs a header list of sz bytes. In this case
the header data is the Familiy, Port and Address, the rest my or may  not be a
binary.

/Tony

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tony.vcf
Type: text/x-vcard
Size: 319 bytes
Desc: Card for Tony Rogvall
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20010105/05651c2b/attachment.vcf>