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.
@@ -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.421";
112
+ export declare const VERSION = "0.4.422";
113
113
  //# sourceMappingURL=constants.d.ts.map
package/dist/constants.js CHANGED
@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
79
79
  reserved: 224,
80
80
  };
81
81
  /** Published package version. Kept in sync with package.json by a test. */
82
- export const VERSION = '0.4.421';
82
+ export const VERSION = '0.4.422';
83
83
  //# sourceMappingURL=constants.js.map
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
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.4.421",
3
+ "version": "0.4.422",
4
4
  "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
5
5
  "keywords": [
6
6
  "edf",
package/src/constants.ts CHANGED
@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
93
93
  } as const;
94
94
 
95
95
  /** Published package version. Kept in sync with package.json by a test. */
96
- export const VERSION = '0.4.421';
96
+ export const VERSION = '0.4.422';