<div dir="ltr">Björn, in solution #1, would you warn only when matching or also when constructing? Is the warning only at compile-time or also at runtime? For example, would you warn for:<div><br></div><div> X = -1.</div><div> <<X>>.<br><div><br></div></div><div>We may have a third option which is to control the masking behaviour with a new flag. From Erlang 19, we could warn if you are relying on masking and you would need to pick to mask (/integer-mask) or fix your code. The default after the warning is removed is to always raise. The mask option wouldn't be supported when matching, making it clear the masking behaviour is construction only.</div><div><br></div><div>I am not sure this is a *good* option but I thought I would mention it anyway. :)</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div><br></div><div><br></div><div><span style="font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José Valim</b></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div><span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" style="color:rgb(42,93,176)" target="_blank">www.plataformatec.com.br</a></span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Skype: jv.ptec</span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and Director of R&D</span></div></span></div></span></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Feb 3, 2016 at 7:17 AM, Björn Gustavsson <span dir="ltr"><<a href="mailto:bjorn@erlang.org" target="_blank">bjorn@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are some gotchas in the bit syntax that comes up now and then on<br>
the mailing list, and also as a bug report at the end of last year:<br>
<a href="http://bugs.erlang.org/browse/ERL-44" rel="noreferrer" target="_blank">http://bugs.erlang.org/browse/ERL-44</a><br>
<br>
We have decided to try do something about it in OTP 19. We have<br>
discussed various solutions internally in the OTP group, and I have<br>
spent far too much time lately thinking about it.<br>
<br>
Here follows first my summary of the issues, and then my suggestion<br>
how the compiler should be modified.<br>
<br>
BACKGROUND ABOUT BIT SYNTAX CONSTRUCTION<br>
<br>
When constructing binaries, there is an implicit masking of the<br>
values. All of the following constructions give the same result:<br>
<br>
<<255>><br>
<<16#FF>><br>
<<16#FFFF>><br>
<<-1>><br>
<br>
There have been complaints about the implicit masking behaviour, but<br>
there is a lot of code that depends on it, so it would be unwise to<br>
change it.<br>
<br>
THE PROBLEM<br>
<br>
There is no similar masking when matching values. That means that all<br>
of the following expressions will all fail to match:<br>
<br>
<<-1>> = <<-1>><br>
<<-1/unsigned>> = <<-1><br>
<<16#FF>> = <<16#FFFF>><br>
<<-12345/signed>> = <<-12345/signed>><br>
<br>
Let's look at how the compiler internally implements matching. Take<br>
this function as an example:<br>
<br>
f(<<-1:8/unsigned>>) -> ok.<br>
<br>
It will be rewritten to:<br>
<br>
f(<<V:8/unsigned>>) when V =:= -1 -> ok.<br>
<br>
That is, an unsigned value (in the range 0-255) will be stored in the<br>
variable V, which will then be compared to -1.<br>
<br>
POSSIBLE SOLUTION #1<br>
<br>
The most obvious solution is probably to let the compiler warn for the<br>
above cases. The matching would still fail. The developer will need to<br>
fix their code. For example:<br>
<br>
<<-1/signed>> = <<-1>><br>
<br>
<br>
POSSIBLE SOLUTION #2<br>
<br>
There is one problem with the solution #1. It is not possible to<br>
produce a warning for the following example:<br>
<br>
f(Val) -><br>
<<Val:8>> = <<Val:8>>,<br>
Val.<br>
<br>
So in addition to warning when possible, another solution is to mask<br>
values also when matching. Internally, the compiler could rewrite the<br>
function to something like:<br>
<br>
f(Val) -><br>
<<NewVar:8>> = <<Val:8>>,<br>
Val = NewVar band 16#FF,<br>
Val.<br>
<br>
Similar rewriting should be done for literal integer, so the following<br>
expression would now match:<br>
<br>
<<-1>> = <<-1>><br>
<br>
<br>
WHICH SOLUTION?<br>
<br>
Just to make to sure that I don't reject solution #2 just because it<br>
seems like a lot work to implement, I have actually implemented it.<br>
<br>
Now that I have implemented solution #2, I want to reject it.<br>
<br>
The reason I reject it is that the matching previously bound variables<br>
is uncommon. Even in the compiler test suites it is uncommon (test<br>
suites typically match bound variables more often than production code<br>
do).<br>
<br>
Therefore, solution #2 would make behaviour of matching more<br>
consistent with construction, but would not significantly increase the<br>
number of correct programs. Also, if clauses that previously didn't<br>
match start to match, then code that has not been executed before will<br>
be executed. Code that has not been tested usually doesn't work.<br>
<br>
Solution #1 would point all cases when literal integers could not<br>
possibly match and force the developer to fix them.<br>
<br>
Therefore I choose solution #1.<br>
<br>
<br>
YOUR INPUT?<br>
<br>
Are there better way to fix bit syntax matching? Anything I have<br>
forgotten or not thought about?<br>
<span class="HOEnZb"><font color="#888888"><br>
/Björn<br>
<br>
--<br>
Björn Gustavsson, Erlang/OTP, Ericsson AB<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</font></span></blockquote></div><br></div>