Dynamic pattern matching of binaries in function heads?

Do binary patterns declared in function heads have to have static sizes? It appears to be the case, but I can’t find documentation one way or the other.

More concretely, it is possible to match a binary with a “#” as the third byte like this:

def foo(<<header::binary-size(2), "#", rest::binary>>), do: something()

But this attempt to make the size of the header dynamic results in an error:

def foo(<<header::binary-size(n), "#", rest::binary>>, n), do: something()

** (CompileError) iex:46: undefined variable "n"

Interestingly, flipping the order of the arguments to the function results in a slightly different error:

def foo(n, <<header::binary-size(n), "#", rest::binary>>), do: something()

** (CompileError) iex:46: undefined variable "n" in bitstring segment. If the size of the binary is a variable, the variable must be defined prior to its use in the binary/bitstring match itself, or outside the pattern match

That error message makes it seem like what I’m trying to do is not possible, but maybe I’m just missing something?


If the size itself precedes the binary data and can be decoded using bitsyntax, this can be done (assuming size is a one-byte unsigned integer):

def foo(<<n::integer, header::binary-size(n), "#", rest::binary>>), do: something()

But not much else beyond leveraging other encodings (bitsize, endianness) of the size prefix, unfortunately.


E.g. in a shell:

# <<n::integer, data::binary-size(n), "#", rest::binary>> = <<5, "hello#rest">>
<<5, 104, 101, 108, 108, 111, 35, 114, 101, 115, 116>>

# n

# data

# rest
1 Like

Thanks, that’s a clear explanation.

I assume this constraint is somehow related to the details of compiling function heads? Because inside of a function, I can pass a variable to the size macro:

def foo(str, n) do
  case str do
    <<header::binary-size(n), "#", rest::binary>> -> something()

Exactly :slight_smile:

So you can just prepend the value to the binary and then it would work?

But would that have a much higher cost than doing the same with lists? Is a new full binary allocated in memory?

So you can just prepend the value to the binary and then it would work?

I definitely would not recommend this, since it will require a new binary to be allocated, as you rightly suggest.

Even if the binaries involved are expected to be small, it seems hard to justify the performance hit for such a tiny spoon of syntactic sugar.

1 Like