You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 13, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: specification.mess
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -13,8 +13,8 @@ SF3 formats follow these principles:
13
13
There are no optional blocks or parts in the formats that could be omitted. This means there is no conditional parsing needed and the structure of the files is always clear.
14
14
- **Only raw data**
15
15
The data is not compressed, encrypted, or otherwise transformed. Data is always raw. If encryption or compression is desired, the entire file can instead be wrapped in a compression or encryption stream (gzip, lzma, etc).
16
-
- **Always little-endian**
17
-
The formats are always little-endian wherever byte order matters. This is compatible with the vast majority of processors and software today and means no byte rearrangement is necessary when loading to memory.
16
+
- **Target recent machines**
17
+
The formats are always little-endian wherever byte order matters, and use 8-bit addressing boundaries. This is compatible with the vast majority of processors and software today and means no byte rearrangement is necessary when loading to memory.
18
18
- **Similar layout**
19
19
Each format in the family follows a very similar format of identifier, header, and payload. This ensures that the files remain easy to parse, understand, and debug.
20
20
@@ -671,7 +671,7 @@ Usually the ``column-length`` will fit exactly one element, meaning it will be t
671
671
672
672
The ``Row`` is specified as an opaque blob in the BNF, but can be easily decoded according to the layout specified by the ``ColumnSpec``s. The data for each column must follow in the same order as the ``ColumnSpec``s inside the row, without any gaps between. A decoder can thus simply iterate over the ``ColumnSpec``s and decode each "cell" by first determining the number of elements, and then decoding each element in the cell according to the ``column-type``.
673
673
674
-
For ``String`` columns especially it should be noted that, due to the null termination, the string may be //shorter// than the number of bytes reserved by the ``column-length``. Unlike other column types, too, a ``String`` column can only ever contain one element.
674
+
For ``String`` columns especially it should be noted that, due to the null termination, the string may be //shorter// than the number of octets reserved by the ``column-length``. Unlike other column types, too, a ``String`` column can only ever contain one element.
675
675
676
676
### Use-Case
677
677
This format lends itself well to structured data that follows a precise schema, especially when new data only needs to be appended such as when recording datapoints. The header fields allow constant-time random access to the rows as well as windowing of the data.
0 commit comments