[erlang-questions] Binaries and Core Erlang

[Aggelos Giantsios]

That actually makes sense.
Thanks for the clarification.

Aggelos

On Sun, Jan 13, 2013 at 10:46 PM, Richard Carlsson <
carlsson.richard@REDACTED> wrote:

> I think the short answer is that the Core Erlang spec was not updated when
> bitstrings were added.
>
>     /Richard
>
>
> On 2013-01-13 18:00, Aggelos Giantsios wrote:
>
>> Hello everybody!!
>>
>> Let's assume we have the following code:
>>
>> -module(foo).
>> bar() -> <<1:3>>.
>>
>> In R15B03, calling foo:bar() evaluates to <<1:3>> as we should expect.
>>
>> Should you compile the module to Core Erlang the resulting code is
>>
>> 'foo'/0 =
>>      fun () ->
>> #{#<1>(3,1,'integer',['**unsigned'|['big']])}#
>>
>> and by using the core_scan and core_parse modules the resulting AST in
>> record format of foo is
>>
>> {c_fun,[],[],
>>         {c_binary,[],
>>                   [{c_bitstr,[],
>>                              {c_literal,[],1},
>>                              {c_literal,[],3},
>>                              {c_literal,[],1},
>>                              {c_literal,[],integer},
>>                              {c_literal,[],[unsigned,big]}}**]}}
>>
>> Having said that, let's try to evaluate the above #c_fun{}.
>> #c_fun{} has no parameters so we use an empty set of bindings and we
>> evaluate #c_binary{}.
>> #c_binary{} evaluates to the concatenation of the [#c_bitstr{}]. We have
>> one #c_bitstr{} so the resulting valu is the value of #c_bitstr{}.
>> #c_bitstr{} evaluates to <<1:3/unsigned-big-integer-**unit:1>> that
>> equals
>> to <<1:3>> making this the overall value of the #c_fun{}, which is
>> consistent with what we got from the interpreter.
>>
>> However, in the Core Erlang 1.0.3 language specs, it explicitly says
>> that the number of bits in the resulting value of a #c_binary{} must be
>> divisible by 8 making it a valid Erlang binary. In this case, the
>> #c_binary{} evaluates to the bitstring <<1:3>> which is not a valid
>> binary. So, in theory, we should have raised an exception at this point.
>> But this is not what happens when we evaluate foo:bar/0 in the
>> interpreter.
>>
>> So is there an inconsistency with the Core Erlang specs or am I missing
>> something?
>>
>> Thanks,
>> Aggelos
>>
>>
>> ______________________________**_________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130114/6c99f765/attachment.htm>