Guide

Loading, creating bitstrings

The basic data type is the Bitstring.bitstring, a string of bits of arbitrary length. Bitstrings can be any length in bits and operations do not need to be byte-aligned (although they will generally be more efficient if they are byte-aligned).

Internally a bitstring is stored as a normal OCaml string together with an offset and length, where the offset and length are measured in bits. Thus one can efficiently form substrings of bitstrings, overlay a bitstring on existing data, and load and save bitstrings from files or other external sources.

To load a bitstring from a file use Bitstring.bitstring_of_file or Bitstring.bitstring_of_chan. There are also functions to create bitstrings from arbitrary data. See the reference section.

Matching bitstrings with patterns

Use the bitstring extension of the match operator (part of the syntax extension) to break apart a bitstring into its fields. match%bitstring works a lot like the OCaml match operator. Please note the use of the {| ... |} verbatim notation for the matching patterns.

The general form of match%bitstring is:

match%bitstring EXPRESSION with

| {| PATTERN |} -> CODE
| {| PATTERN |} -> CODE
|  ...

As with normal match, the statement attempts to match the bitstring against each pattern in turn. If none of the patterns match then the standard library Match_failure exception is thrown.

Patterns look a bit different from normal match patterns. They consist of a list of bitfields separated by ; where each bitfield contains a bind variable, the width (in bits) of the field, and other information. Some example patterns:

match%bitstring bits with

| {| version : 8; name : 8; param : 8 |} -> ...

   (* Bitstring of at least 3 bytes. First byte is the version
      number, second byte is a field called name, third byte is
      a field called parameter. *)

| {| flag : 1 |} ->
   printf "flag is %b\n" flag

   (* A single flag bit (mapped into an OCaml boolean). *)

| {| len : 4; data : 1 + len |} ->
   printf "len = %d, data = 0x%Lx\n" len data

   (* A 4-bit length, followed by 1-16 bits of data, where the
      length of the data is computed from len. *)

| {| ipv6_source : 128 : bitstring;
     ipv6_dest   : 128 : bitstring |} -> ...

   (* IPv6 source and destination addresses. Each is 128 bits
      and is mapped into a bitstring type which will be a substring
      of the main bitstring expression. *)

You can also add conditional when-clauses:

| {| version : 4 |}
    when version = 4 || version = 6 -> ...

   (* Only match and run the code when version is 4 or 6. If
      it isn't we will drop through to the next case. *)

Note that the pattern is only compared against the first part of the bitstring (there may be more data in the bitstring following the pattern, which is not matched). In terms of regular expressions you might say that the pattern matches ^pattern, not ^pattern$. To ensure that the bitstring contains only the pattern, add a length -1 bitstring to the end and test that its length is zero in the when-clause:

| {| n : 4;
     rest : -1 : bitstring |}
     when Bitstring.bitstring_length rest = 0 -> ...

   (* Only matches exactly 4 bits. *)

Normally the first part of each field is a binding variable, but you can also match a constant, as in:

| {| (4|6) : 4 |} -> ...

   (* Only matches if the first 4 bits contain either the integer 4 or the integer 6. *)

One may also match on strings:

| {| "MAGIC" : 5*8 : string |} -> ...

   (* Only matches if the string "MAGIC" appears at the start of the input. *)

Pattern field reference

The exact format of each pattern field is:

pattern : length [: qualifier [,qualifier ...]]

pattern is the pattern, binding variable name, or constant to match. length is the length in bits which may be either a constant or an expression. The length expression is just an OCaml expression and can use any values defined in the program, and refer back to earlier fields (but not to later fields).

Integers can only have lengths in the range [1..64] bits. See the integer types section below for how these are mapped to the OCaml int/int32/int64 types. This is checked at compile time if the length expression is constant, otherwise it is checked at runtime and you will get a runtime exception eg. in the case of a computed length expression.

A bitstring field of length -1 matches all the rest of the bitstring (thus this is only useful as the last field in a pattern).

A bitstring field of length 0 matches an empty bitstring (occasionally useful when matching optional subfields).

Qualifiers are a list of identifiers/expressions which control the type, signedness and endianness of the field. Permissible qualifiers are:

Qualifier	Description
`int`	field has an integer type
`string`	field is a string type
`bitstring`	field is a bitstring type
`signed`	field is signed
`unsigned`	field is unsigned
`bigendian`	field is big endian - a.k.a network byte order
`littleendian`	field is little endian - a.k.a Intel byte order
`nativeendian`	field is same endianness as the machine
`endian(expr)`	`expr` should be an expression which evaluates to a `Bitstring.endian` type
`offset(expr)`	see computed offsets below
`check(expr)`	apply some constraint to the field
`bind(expr)`	bind the field to `expr`
`map(lambda)`	apply `lambda` to the field

Bitstring.endian is either LittleEndian, BigEndian or NativeEndian. The expression in endian(expr) is an arbitrary OCaml expression and can use the value of earlier fields in the bitmatch.

The default settings are int, unsigned, bigendian, no offset.

Note that many of these qualifiers cannot be used together, eg. bitstrings do not have endianness. The syntax extension should give you a compile-time error if you use incompatible qualifiers.

Default match cases

As well as a list of fields, it is possible to name the bitstring and/or have a default match case:

| {| _ |} -> ...

   (* Default match case. *)

| {| _ |} as pkt -> ...

   (* Default match case, with 'pkt' bound to the whole bitstring. *)

Function definition

The function keyword can also be used for pattern matching:

let pattern_matcher = function%bitstring
| {| false : 1
   ; a : 2
   ; b : 16 : bigendian
   ; ...
   |} -> (* Do something *)
| {| _ |} -> (* Do something else *)

Constructing bitstrings

Bitstrings may be constructed using the bitstring extension of the let keyword. The let%bitstring expression takes a list of fields, similar to the list of fields for matching:

let version = 1 ;;
let data = 10 ;;
let%bitstring bits = {|
  version : 4;
  data : 12
|} ;;

(* Constructs a 16-bit bitstring with the first four bits containing
   the integer 1, and the following 12 bits containing the integer 10,
   arranged in network byte order. *)

Bitstring.hexdump_bitstring stdout bits ;;

(* Prints:
   00000000  10 0a         |..              |
 *)

The format of each field is the same as for pattern fields (see Pattern field reference section), and things like computed length fields, fixed value fields, insertion of bitstrings within bitstrings, etc. are all supported.

Construction exception

The let%bitstring expression may throw a Bitstring.Construct_failure exception at runtime.

Runtime errors include:

int field length not in the range [1..64]
a bitstring with a length declared which doesn't have the same length at runtime
trying to insert an out-of-range value into an int field

Integer types

Integer types are mapped to OCaml types bool, int, int32 or int64 using a system which tries to ensure that (a) the types are reasonably predictable and (b) the most efficient type is preferred.

The rules are slightly different depending on whether the bit length expression in the field is a compile-time constant or a computed expression.

Detection of compile-time constants is quite simplistic so only simple integer literals and simple expressions (eg. 5 * 8) are recognized as constants.

In any case the bit size of an integer is limited to the range [1..64]. This is detected as a compile-time error if that is possible, otherwise a runtime check is added which can throw an Invalid_argument exception.

The mapping is thus:

Bit size	Constant	Computed expression
1	`bool`	`int64`
2..31	`int`	`int64`
32	`int32`	`int64`
33..64	`int64`	`int64`

A possible future extension may allow people with 64 bit computers to specify a more optimal int type for bit sizes in the range 32..63. If this was implemented then such code could not even be compiled on 32 bit platforms, so it would limit portability.

Another future extension may be to allow computed expressions to assert min/max range for the bit size, allowing a more efficient data type than int64 to be used. (Of course under such circumstances there would still need to be a runtime check to enforce the size).

Advanced pattern-matching

Computed offsets

You can add an offset(..) qualifier to bitmatch patterns in order to move the current offset within the bitstring forwards.

For example:

match%bitstring bits with
| {| field1 : 8;
     field2 : 8 : offset(160) |} -> ...

matches field1 at the start of the bitstring and field2 at 160 bits into the bitstring. The middle 152 bits go unmatched (ie. can be anything).

The generated code is efficient. If field lengths and offsets are known to be constant at compile time, then almost all runtime checks are avoided. Non-constant field lengths and/or non-constant offsets can result in more runtime checks being added.

Note that moving the offset backwards, and moving the offset in let%bitstring expressions, are both not supported at present.

Check expressions

You can add a check(expr) qualifier to bitmatch patterns. If the expression evaluates to false then the current match case fails to match (in other words, we fall through to the next match case - there is no error).

For example:

match%bitstring bits with
| { field : 16 : check (field > 100) } -> ...

Note the difference between a check expression and a when-clause is that the when-clause is evaluated after all the fields have been matched. On the other hand a check expression is evaluated after the individual field has been matched, which means it is potentially more efficient (if the check expression fails then we don't waste any time matching later fields).

We wanted to use the notation when(expr) here, but because when is a reserved word we could not do this.

Bind expressions

A bind expression is used to change the value of a matched field. For example:

match%bitstring bits with
| { len : 16 : bind (len * 8);
    field : len : bitstring } -> ...

In the example, after 'len' has been matched, its value would be multiplied by 8, so the width of 'field' is the matched value multiplied by 8.

In the general case:

| { field : ... : bind (expr) } -> ...

evaluates the following after the field has been matched:

let field = expr in
   (* remaining fields *)

Map expressions

A map expression is used to apply a lambda expression to a matched field. The matched field would then contain the result of the application:

{| field : size : map (fun v -> do_something_with v) }|

evaluates the following after the field has been matched:

let field = (fun v -> do_something_with v) temporary_parsed_field in
   (* remaining fields *)

Order of evaluation

The choice is arbitrary, but we have chosen that check expressions are evaluated first, and bind/map expressions are evaluated after.

This means that the result of bind() or map() is not available in the check expression.

Note that this rule applies regardless of the order of check(), bind(), or map() in the source code.

Saving bit offsets

Use save_offset_to(variable) to save the current bit offset within the match to a variable (strictly speaking, to a pattern). This variable is then made available in any check() and bind() clauses in the current field, and to any later fields, and to the code after the ->.

For example:

match%bitstring bits with
| {| len : 16;
     _ : len : bitstring;
     field : 16 : save_offset_to (field_offset) |} ->
      printf "field is at bit offset %d in the match\n" field_offset

(In that example, field_offset should always have the value len+16).

Security and type safety

Security on input

The main concerns for input are buffer overflows and denial of service.

It is believed that this library is robust against attempted buffer overflows. In addition to OCaml's normal bounds checks, we check that field lengths are >= 0, and many additional checks.

Denial of service attacks are more problematic. We only work forwards through the bitstring, thus computation will eventually terminate. As for computed lengths, code such as this is thought to be secure:

match%bitstring bits with
| {| len : 64;
     buffer : Int64.to_int len : bitstring |} -> ...

The len field can be set arbitrarily large by an attacker, but when pattern-matching against the buffer field this merely causes a test such as if len <= remaining_size to fail. Even if the length is chosen so that buffer bitstring is allocated, the allocation of sub-bitstrings is efficient and doesn't involve an arbitary-sized allocation or any copying.

However the above does not necessarily apply to strings used in matching, since they may cause the library to use the Bitstring.string_of_bitstring function, which allocates a string. So you should take care if you use the string type particularly with a computed length that is derived from external input.

The main protection against attackers should be to ensure that the main program will only read input bitstrings up to a certain length, which is outside the scope of this library.

Security on output

As with the input side, computed lengths are believed to be safe. For example:

let len = read_untrusted_source () in
let buffer = allocate_bitstring () in
[%bitstring {|
  buffer : len : bitstring
|}]

This code merely causes a check that buffer's length is the same as len. However the program function allocate_bitstring must refuse to allocate an oversized buffer (but that is outside the scope of this library).

Order of evaluation

In match%bitstring statements, fields are evaluated left to right.

Note that the when-clause is evaluated last, so if you are relying on the when-clause to filter cases then your code may do a lot of extra and unncessary pattern-matching work on fields which may never be needed just to evaluate the when-clause. Either rearrange the code to do only the first part of the match, followed by the when-clause, followed by a second inner bitmatch, or use a check() qualifier within fields.

Safety

The current implementation is believed to be fully type-safe, and makes compile and run-time checks where appropriate. If you find a case where a check is missing please submit a bug report or a patch.

Limits

These are thought to be the current limits:

Integers: [1..64] bits.
Bitstrings (32-bit): maximum length is limited by the string size, ie. 16 MBytes.
Bitstrings (64-bit): maximum length is thought to be limited by the string size, ie. effectively unlimited.

Bitstrings must be loaded into memory before we can match against them. Thus available memory may be considered a limit for some applications.