edfcore 0.5.62 → 0.5.64

package/dist/constants.d.ts

@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
     readonly reserved: 224;
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export declare const VERSION = "0.5.62";
+export declare const VERSION = "0.5.64";
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.js

@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
     reserved: 224,
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.5.62';
+export const VERSION = '0.5.64';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,56 @@ alone does not tell you whether you were affected.
 edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
 defect; those are called out below.
 
+## 0.5.64
+
+- **Added** the reading half of "edfcore reads, it does not write". `reads-not-writes.test.ts`
+  checks the five places the package SAYS so — the README, AGENTS.md, `comparison.md`,
+  `design-decisions.md` and the npm keywords — and all five are about the missing feature: edfcore
+  produces no EDF files. None of them is about the bytes you already have, which is the exposure a
+  caller has without reading a page.
+- It is structural rather than hypothetical. `byteSource` is zero-copy, so `readRecordBytes` hands
+  `decodeInt16` a `subarray` of the caller's own array, and a decode loop that wrote where it meant
+  to read would corrupt the caller's copy of their recording in place — with nothing downstream
+  looking wrong, because the samples returned would still be the samples that were there.
+- `we-never-write-your-bytes.test.ts` captures the buffer, runs open, index, a full validation
+  sweep, inspect, annotations, records, windows, envelopes, a stream and scaling over it, and
+  requires it byte for byte afterwards — over all ten `AWKWARD` shapes and a gapped file, in two
+  wirings.
+- The two wirings are the point. Behind `cachedSource` every decode runs over the cache's own copy,
+  so a write in the decoder can never reach the caller and that half of the sweep would pass
+  regardless. Unwrapped is the case that carries the property. Putting an in-place write in
+  `decodeInt16` fails the unwrapped half on eight files and leaves the cached half green, which is
+  what makes the distinction worth spelling out rather than wiring one and moving on.
+- `fileSource` is asked the same thing of the filesystem, where a write would be worse: the bytes
+  on disk and the file's modification time both survive a full read. And the one buffer edfcore
+  does write into is asserted to BE written — `out` on `toPhysical` — so the rule reads as a rule
+  and not as a tautology.
+
+## 0.5.63
+
+- **Added** the other half of the zero-copy bargain. `byteSource` is documented as handing out
+  `subarray` views over the caller's own buffer, and `io/bytes.ts` argues that is safe because the
+  adapter retains nothing the caller does not already hold. That is a claim about the ADAPTER. The
+  values the reading API builds out of those views are what a caller keeps, and nothing said
+  whether any of them still points at the buffer.
+- Two sites state the rule for themselves and neither was checked: `header/parse.ts` copies the
+  header bytes so "a header that quietly changed under a hexdump" cannot happen, and
+  `diagnostics/collector.ts` copies a diagnostic's evidence because "a diagnostic outlives the read
+  that produced it".
+- The second is the one holding it up. `readHeader` joins its two reads into a buffer of its own,
+  so the header is copied twice over and the `copyBytes` there is belt on braces. The four
+  `rawBytes` in `tal/` are `sliceBytes` — a `subarray` of the record bytes — and `readRecordBytes`
+  returns those straight from the source. Removing the collector's `.slice()` makes a
+  `TAL_MALFORMED` diagnostic hand back a window into the caller's file, and this file fails.
+- `nothing-points-at-your-buffer.test.ts` walks every value every entry point returns over all ten
+  `AWKWARD` shapes, a gapped file and one whose TAL onsets are not numbers, and requires every
+  typed array to be backed by some other buffer. Then it overwrites the caller's bytes end to end
+  and compares each answer against a `structuredClone` taken before — the failure a caller would
+  actually meet, having reused the array they fetched into.
+- Two assertions keep it honest: that a `byteSource` read really does alias, so the risk is real,
+  and that the sweep reached a diagnostic quoting record bytes rather than only the header, so a
+  pass is not a pass on the one path that was never in question.
+
 ## 0.5.62
 
 - **Fixed** `byteSource` accepting a detached `ArrayBuffer` and building a zero-byte source over

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.5.62",
+  "version": "0.5.64",
   "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
   "keywords": [
     "edf",

package/src/constants.ts

@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
 } as const;
 
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.5.62';
+export const VERSION = '0.5.64';