[erlang-questions] bit syntax: what does "<<1234>> =" match?

[Anthony Ramine]

Le 28 févr. 2011 à 14:15, Robert Virding a écrit :

> ----- "Anthony Ramine" <nox@REDACTED> wrote:
> 
>> Le 28 févr. 2011 à 01:40, Robert Virding a écrit :
>> 
>>> 
>>> ----- "Anthony Ramine" <nox@REDACTED> wrote:
>>> 
>>>> Le 26 févr. 2011 à 20:28, Robert Virding a écrit :
>>>> 
>>>>> One of the cool things with binaries is that there is no info in
>> the
>>>> binary saying how it was created so I can do lots of fun things
>> when I
>>>> pull it apart.
>>>>> 
>>>>> Robert
>>>> 
>>>> While it may be cool, I think the compiler should issue a warning
>> when
>>>> an impossible pattern is encountered. 1234 is obviously not
>>>> representable with only 8 bits.
>>> 
>>> The coolness was not an impossible pattern, I agree that the
>> compiler should warn, but more the fact that you can pull apart a
>> binary differently from how it was constructed. It is with that you
>> can do cool things.
>>> 
>>> Robert
>> 
>> That certainly looks impossible to me, how can you match <<1234>>? You
>> make it sound like if you know the underlying binary representation
>> you can match it.
> 
> Quite the opposite. <<1234>> is definitely as impossible pattern, and constructor for that matter, as the default in a binary without any type or size specifier is an 8-bit integer. And 1234 is not an 8-bit integer. I think the system *should* complain.
> 
> What I meant is that you can do things like:
> 
> <<Sign:1,Exponent:11,Significand:52>> = << 1.234:64/float >>
> 
> (with reservation for the order) where you pull apart a 64-bit floating point number into its components. You construct a binary with a floating-point number and pull it apart into three integers. That is cool.
> 
> Robert

So we agree, but I misread what you said and thought the opposite ;)
The compiler does not complain with <<1234>> and that's already weird as it is. It gets to a whole new level of weirdness when you discover that <<foo>> is also a legal pattern even though it won't ever match.

--
Anthony Ramine
Dev:Extend
http://dev-extend.eu