404 - Not found
++ FlatBuffers has migrated their documentation system recently. + + Please file an issue indicating the broken link. + +
commit ea25e8610b0f02527356f3035eada35aae125b33 Author: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Date: Sat Apr 18 00:09:31 2026 +0000 Deployed ac7ef11 with MkDocs version: 1.6.1 diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 000000000..e69de29bb diff --git a/404.html b/404.html new file mode 100644 index 000000000..19b3073cf --- /dev/null +++ b/404.html @@ -0,0 +1,1410 @@ + + + +
+ + + + + + + + + + + + + + + + + +This provides a way to annotate flatbuffer binary data, byte-by-byte, with a +schema. It is useful for development purposes and understanding the details of +the internal format.
+Given a schema, as either a plain-text (.fbs) or a binary schema (.bfbs),
+and binary file(s) that were created by the schema. You can annotate them
+using:
flatc --annotate SCHEMA -- BINARY_FILES...
+This will produce a set of annotated files (.afb Annotated FlatBuffer)
+corresponding to the input binary files.
Taken from the tests/annotated_binary.
+cd tests/annotated_binary
+../../flatc --annotate annotated_binary.fbs -- annotated_binary.bin
+Which will produce a annotated_binary.afb file in the current directory.
The annotated_binary.bin is the flatbufer binary of the data contained within
+annotated_binary.json, which was made by the following command:
..\..\flatc -b annotated_binary.fbs annotated_binary.json
+Currently there is a built-in text-based format for outputting the annotations.
+A full example is shown here:
+annotated_binary.afb
The data is organized as a table with fixed columns grouped into
+Binary sections and regions, starting
+from the beginning of the binary (offset 0).
The columns are as follows:
+The offset from the start of the binary, expressed in hexadecimal format
+ (e.g. +0x003c).
The prefix + is added to make searching for the offset (compared to some
+random value) a bit easier.
The raw binary data, expressed in hexadecimal format.
+This is in the little endian format the buffer uses internally and what you +would see with a normal binary text viewer.
+The type of the data.
+This may be the type specified in the schema or some internally defined +types:
+| Internal Type | +Purpose | +
|---|---|
VOffset16 |
+Virtual table offset, relative to the table offset | +
UOffset32 |
+Unsigned offset, relative to the current offset | +
SOffset32 |
+Signed offset, relative to the current offset | +
The value of the data.
+This is shown in big endian format that is generally written for humans to
+consume (e.g. 0x0013). As well as the "casted" value (e.g. 0x0013is
+19 in decimal) in parentheses.
Notes about the particular data.
+This describes what the data is about, either some internal usage, or tied +to the schema.
+The file is broken up into Binary Sections, which are comprised of contiguous
+binary regions that are logically grouped together. For
+example, a binary section may be a single instance of a flatbuffer Table or
+its vtable. The sections may be labelled with the name of the associated type,
+as defined in the input schema.
An example of a vtable Binary Section that is associated with the user-defined
+AnnotateBinary.Bar table.
vtable (AnnotatedBinary.Bar):
+ +0x00A0 | 08 00 | uint16_t | 0x0008 (8) | size of this vtable
+ +0x00A2 | 13 00 | uint16_t | 0x0013 (19) | size of referring table
+ +0x00A4 | 08 00 | VOffset16 | 0x0008 (8) | offset to field `a` (id: 0)
+ +0x00A6 | 04 00 | VOffset16 | 0x0004 (4) | offset to field `b` (id: 1)
+These are purely annotative, there is no embedded information about these +regions in the flatbuffer itself.
+Binary regions are contiguous bytes regions that are grouped together to form
+some sort of value, e.g. a scalar or an array of scalars. A binary region may
+be split up over multiple text lines, if the size of the region is large.
Looking at an example binary region:
+vtable (AnnotatedBinary.Bar):
+ +0x00A0 | 08 00 | uint16_t | 0x0008 (8) | size of this vtable
+The first column (+0x00A0) is the offset to this region from the beginning of
+the buffer.
The second column are the raw bytes (hexadecimal) that make up this region. +These are expressed in the little-endian format that flatbuffers uses for the +wire format.
+The third column is the type to interpret the bytes as. For the above example,
+the type is uint16_t which is a 16-bit unsigned integer type.
The fourth column shows the raw bytes as a compacted, big-endian value. The raw
+bytes are duplicated in this fashion since it is more intuitive to read the data
+in the big-endian format (e.g., 0x0008). This value is followed by the decimal
+representation of the value (e.g., (8)). For strings, the raw string value is
+shown instead.
The fifth column is a textual comment on what the value is. As much metadata as +known is provided.
+If the type in the 3rd column is of an absolute offset (SOffet32 or
+Offset32), the fourth column also shows an Loc: +0x025A value which shows
+where in the binary this region is pointing to. These values are absolute from
+the beginning of the file, their calculation from the raw value in the 4th
+column depends on the context.
0&&i[i.length-1])&&(p[0]===6||p[0]===2)){r=0;continue}if(p[0]===3&&(!i||p[1]>i[0]&&p[1]=e.length&&(e=void 0),{value:e&&e[o++],done:!e}}};throw new TypeError(t?"Object is not iterable.":"Symbol.iterator is not defined.")}function K(e,t){var r=typeof Symbol=="function"&&e[Symbol.iterator];if(!r)return e;var o=r.call(e),n,i=[],s;try{for(;(t===void 0||t-- >0)&&!(n=o.next()).done;)i.push(n.value)}catch(a){s={error:a}}finally{try{n&&!n.done&&(r=o.return)&&r.call(o)}finally{if(s)throw s.error}}return i}function B(e,t,r){if(r||arguments.length===2)for(var o=0,n=t.length,i;o