edfcore 0.4.421 → 0.4.422
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/docs/CHANGELOG.md +21 -0
- package/package.json +1 -1
- package/src/constants.ts +1 -1
package/dist/constants.d.ts
CHANGED
|
@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
|
|
|
109
109
|
readonly reserved: 224;
|
|
110
110
|
};
|
|
111
111
|
/** Published package version. Kept in sync with package.json by a test. */
|
|
112
|
-
export declare const VERSION = "0.4.
|
|
112
|
+
export declare const VERSION = "0.4.422";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,27 @@ alone does not tell you whether you were affected.
|
|
|
6
6
|
edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
|
|
7
7
|
defect; those are called out below.
|
|
8
8
|
|
|
9
|
+
## 0.4.422
|
|
10
|
+
|
|
11
|
+
- **Added** tests for what `byteSource` accepts and what it says about everything else. It is the
|
|
12
|
+
first call almost everyone makes, and the one place a caller's mistake can be mistaken for a
|
|
13
|
+
defect in their file: `new Uint8Array(x)` accepts almost anything — a string, a plain object and
|
|
14
|
+
`null` all yield an empty array, a `number[]` one of the wrong length — so a source built from
|
|
15
|
+
any of them reads back as `[SOURCE_TOO_SMALL] the header is 0 bytes`, blaming the recording for
|
|
16
|
+
an argument.
|
|
17
|
+
- Two acceptances are load-bearing and neither is obvious from the signature. A Node `Buffer`
|
|
18
|
+
works because it is a `Uint8Array`, and `await readFile(path)` is how almost everyone in Node
|
|
19
|
+
gets bytes. A buffer or view from another realm works because the guard is
|
|
20
|
+
`Object.prototype.toString`, not `instanceof` — until 0.3.20 the ArrayBuffer half used
|
|
21
|
+
`instanceof` while the SharedArrayBuffer half already used the tag, so a real, usable
|
|
22
|
+
ArrayBuffer from an iframe was refused as "a plain object" and told to pass the ArrayBuffer
|
|
23
|
+
itself, which is what the caller had done. That case now runs through `node:vm`, because a
|
|
24
|
+
same-realm buffer passes `instanceof` and would let the defect back in unnoticed.
|
|
25
|
+
- Two refusals are load-bearing too. An `Int8Array` has one byte per element, so it passes every
|
|
26
|
+
length check and then has its already-signed elements sign-extended a second time during decode:
|
|
27
|
+
fabricated microvolts with no error anywhere. A `DataView` is the other shape that looks like
|
|
28
|
+
bytes and is not.
|
|
29
|
+
|
|
9
30
|
## 0.4.421
|
|
10
31
|
|
|
11
32
|
- **Fixed** the first line of `edfcore validate`, which did not pluralise. A report with two errors
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED