[erlang-questions] binary_to_term

[Michael Radford]

Claes Wikstrom writes:
> Hmm, I have a real hard time believing that there indeed are
> such applications. All apps that use binary_to_term in
> some way or an other either use sockets with {packet, X}
> or if they write terms to disk, make up their own frames.
> 
> So - IMHO - changing this will not break anything. What's
> even more irritating here - is that this issue is probably
> originally my fault :-(

It will break any code that relies on the current behavior.

Let's imagine there's a function erlang:binary_prefix_to_term/1
which does exactly what binary_to_term does now.

That function (under that name) should hardly be controversial --
binary_prefix_to_term is always safe to call, and its output is always
well defined for any input.  It might be more convenient than a strict
version of binary_to_term, in situations where you know that the prefix
of a binary is an encoded term, and you don't want to bother
constructing a sub-binary of the exact length.

> All apps that store or receive binaries that are later to be
> turned into terms MUST use some framing. Thus any apps that
> break here are already broken - someway - since they're discarding
> data.

No, because they are not necessarily discarding the data -- the extra
data could be part of a larger structure.

Now, I'm not saying that this is an important aspect of binary_to_term,
just that it's not unsafe, that it has valid use cases, and that the
only "terrible" thing here is that people expectations are incorrect.

Mike