[erlang-questions] R14B gen_tcp:recv/2,3

[Ingela Andin]

Hi!

This change does break backwards compatibility.  The reason we changed
it was that we want  gen_tcp and ssl to behave the same, if possible.
Ssl did behave according to the documentation and in the intended way,
so the gen_tcp behavior is considered a bug.
Either way to make them behave the same we had to break backwards compatibility
for either gen_tcp or ssl. Also http-packet mode has not been
supported very long,
actually we made it supported for the sake of ssl so that new ssl could
support http-packet mode and not break applications using it.
As for supporting more than one OTP-version, it should be no problem having a
error clause that will be dead code in R14 and do something in
previous versions.
The content of the http_error tuple should not be any different from before.

Regards Ingela Erlang/OTP team - Ericsson AB


2010/9/17 Bengt Kleberg <bengt.kleberg@REDACTED>:
> One more thing. I hope you are not contemplating having different
> versions of your code for different versions of the erlang VM.
>
> If you code like this:
>
> case gen_tcp:recv(Sock, Len, RecvTimeout)
> of {ok, {http_error,String}} -> {error, Reason}
> ; {ok, Bin} -> {ok, Bin}
> ; {error, Reason} -> {error, Reason}
> end.
>
> it will work on both versions of the erlang VM.
>
>
> bengt
>
> On Fri, 2010-09-17 at 09:29 +0200, Roberto Ostinelli wrote:
>> > Greetings,
>> >
>> > If (I have not read the document) gen_tcp:recv/2,3 returns {ok,
>> > {http_error,String}} your have a matching clause. Unfortunately the
>> > match means that Bin will be {http_error,String}, which is probably not
>> > what you want.
>> >
>>
>> hi bengt,
>>
>> my code was just making a statement and is indeed incorrect.
>>
>> i do have quite some code which relies on {packet, http} and passive
>> mode, so i believe i might be confronted with adding code which
>> handles running on different versions of the erlang VM. *if* i'm
>> not misunderstanding, this does break backwards compatibility and i'm
>> quite surprised, to the point i'm asking this list for confirmation.
>>
>> r.
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>