| Author |
Message |
|
| mtruog |
 Posted: Wed Oct 28, 2009 7:31 pm |
 |
|
|
User
Joined: 07 Feb 2009
Posts: 50
Location: San Francisco, CA
|
When {active, false} and {packet, http} are used with gen_tcp:connect/2
there is a difference between what dialyzer (in R13B02-1 or R13B01)
expects and what happens in reality. Based on the code here:
erts/emulator/beam/erl_bif_port.c on line 1230 in R13B02-1
It makes sense that you can get a response {ok, {http_error, _}} when
calling "case gen_tcp:recv(Socket, 0, Timeout) of" and this is the
result dialyzer expects. However, in reality I get {error, {http_error,
_}} and need to make sure my code is {_, {http_error, _}} to avoid the
problem. I am not sure what is changing the output of
erlang:decode_packet/3.
- Michael
________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
   
|
| Guest |
| Posted: Thu Oct 29, 2009 11:15 am |
|
|
|
Guest
|
Hi,
gen_tcp:recv has been returning {error,{http_error,_}} instead of
{ok,{...}} since the beginning (when it was an undocumented feature used
by some privileged applications), so I don't think we can change that
without breaking backwards compatibility. I guess we have to introduce
this "exception to the rule" in both the documentation and dialyzer.
About the code:
gen_tcp with {packet,http} does not use erlang:decode_packet or any of
the http related code in erl_bif_port.c.
The common code used by both gen_tcp and decode_packet is in
beam/packet_parser.c.
The terms returned from the socket are then contructed by code in
emulator/drivers/common/inet_drv.c.
/Sverker, Erlang/OTP Ericsson
Michael Truog wrote:
> When {active, false} and {packet, http} are used with gen_tcp:connect/2
> there is a difference between what dialyzer (in R13B02-1 or R13B01)
> expects and what happens in reality. Based on the code here:
> erts/emulator/beam/erl_bif_port.c on line 1230 in R13B02-1
>
> It makes sense that you can get a response {ok, {http_error, _}} when
> calling "case gen_tcp:recv(Socket, 0, Timeout) of" and this is the
> result dialyzer expects. However, in reality I get {error, {http_error,
> _}} and need to make sure my code is {_, {http_error, _}} to avoid the
> problem. I am not sure what is changing the output of
> erlang:decode_packet/3.
>
> - Michael
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>
>
________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Oct 29, 2009 3:47 pm |
|
|
|
Guest
|
Sverker Eriksson wrote:
> Hi,
>
> gen_tcp:recv has been returning {error,{http_error,_}} instead of
> {ok,{...}} since the beginning (when it was an undocumented feature used
> by some privileged applications), so I don't think we can change that
> without breaking backwards compatibility. I guess we have to introduce
> this "exception to the rule" in both the documentation and dialyzer.
I do not really see any problem as far as backwards compatibility for
the masses is concerned. Even today, the documented behaviour of
gen_tcp (http://www.erlang.org/doc/man/gen_tcp.html) reads:
recv(Socket, Length) -> {ok, Packet} | {error, Reason}
recv(Socket, Length, Timeout) -> {ok, Packet} | {error, Reason}
Types:
Socket = socket()
Length = int()
Packet = [char()] | binary()
Timeout = int() | infinity
Reason = closed | posix()
where posix() is an atom.
Programs that explicitly match on {error, {http_error, _}} rely on
something undocumented and they should know better that this could
change at any time.
Moreover, dialyzer exists and automatically identifies all these places
in the code and is there to help users in changing them.
What's the problem in making the right decision here?
Erlang has too many inconsistent return values in its key functions.
Does it need another one?
Kostis
________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Oct 29, 2009 4:41 pm |
|
|
|
Guest
|
Kostis Sagonas wrote:
> :
>
> Programs that explicitly match on {error, {http_error, _}} rely on
> something undocumented and they should know better that this could
> change at any time.
>
> Moreover, dialyzer exists and automatically identifies all these
> places in the code and is there to help users in changing them.
>
> What's the problem in making the right decision here?
>
Fear of breaking "established" applications such as Yaws and Mochiweb, I
guess...
> Erlang has too many inconsistent return values in its key functions.
> Does it need another one?
>
No, maybe we should muster the courage to do the right thing then...
/Sverker, Erlang/OTP
________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
