edfcore 0.4.458 → 0.4.460
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 +33 -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.460";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,39 @@ 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.460
|
|
10
|
+
|
|
11
|
+
- **Added** the fourth rung of `timekeepingDefect`'s ladder, which had never run: a timekeeping
|
|
12
|
+
TAL written `+t 0x14 0x14 0x14 0x00` — two empty texts where the grammar allows exactly one.
|
|
13
|
+
- The other three rungs were covered. Text merged into the timekeeping TAL is the destructive one
|
|
14
|
+
and has its own file; a stray duration and the widespread `+t 0x14 0x00` shorthand are both
|
|
15
|
+
benign and both tested. This is the shorthand's opposite — a writer looping over an events list
|
|
16
|
+
that happens to be empty and terminating each iteration anyway — and deleting the check for it
|
|
17
|
+
failed nothing.
|
|
18
|
+
- Pinned as BENIGN, which is the part that matters. The two kinds carry separate once-per-call
|
|
19
|
+
flags, and a rung landing on the destructive side would report every record of a file whose
|
|
20
|
+
writer does this throughout. The fixture makes all three records malformed and asserts one
|
|
21
|
+
report, with the "nothing was lost" advice rather than the "EVERY affected record" advice.
|
|
22
|
+
- And the onset still governs the timeline: the span is asserted, so a rung that reported the
|
|
23
|
+
defect while losing the timing would fail here rather than pass quietly.
|
|
24
|
+
|
|
25
|
+
## 0.4.459
|
|
26
|
+
|
|
27
|
+
- **Added** the two `COMMA_DECIMAL_SEPARATOR` cases that were missing: a comma in the declared
|
|
28
|
+
header size, and a comma in the record count.
|
|
29
|
+
- `readNumericField` exists for exactly those two fields, because both have an authoritative
|
|
30
|
+
alternative — the computed header size always wins, and the record count is recoverable from the
|
|
31
|
+
source length. Both were tested only with values that recover, so the one line in that function
|
|
32
|
+
which does NOT recover had never run. Deleting it changed nothing visible: the comma fell through
|
|
33
|
+
to `!parse.ok`, became `NaN`, and was quietly replaced.
|
|
34
|
+
- That silence is what the refusal is for. `"1,024"` in the record count is one thousand and
|
|
35
|
+
twenty-four records to the writer that wrote it; recovering from the source length yields a
|
|
36
|
+
plausible number that is right only by accident, and `recordCount` is what every read range in
|
|
37
|
+
the library is checked against.
|
|
38
|
+
- The contrast is asserted alongside it — any other bad value in those two fields still recovers,
|
|
39
|
+
with `RECORD_COUNT_RECOVERED` or `HEADER_SIZE_MISMATCH` — so the new cases pin the comma as the
|
|
40
|
+
exception rather than pinning the fields as fatal.
|
|
41
|
+
|
|
9
42
|
## 0.4.458
|
|
10
43
|
|
|
11
44
|
- **Added** tests for a bad HTTP status during a READ, which had never run. `httpSource` reports a
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED