10 most recent check-ins occurring on or after 2026-09-18 12:48:02.
More ↑
|
2026-09-20
| ||
| 22:07 |
tarball and zip: consume the end-of-options marker
The marker branch fell through to the operand slots, so it took VERSION's place and OUTPUTFILE was refused. A value option's argument is now also taken before the marker is considered. Release 0.3.26. check-in: 28cd7f506a user: dmestas tags: trunk, version-0.3.26 | |
| 13:25 |
Release 0.3.25
A bare -- ends the options in every verb; zip names are flagged UTF-8. check-in: 726efdca6b user: dmestas tags: trunk, version-0.3.25 | |
| 13:03 |
cli: honour a bare -- as end of options in every verb
A file whose name begins with '-' could not be named at all: passed bare it parses as a flag, and './-x.txt' parses and then matches nothing, because a path is compared literally against the check-in's file list. A forge serving such a repository answered 500 for every content route on that file. Twenty parsers already honoured the marker, including the shared flag scanner behind add, rm, commit and mv; the twenty-five with hand-written loops did not, cat among them. Each now gates its flag branches behind the marker, so operands fall through to the positional handling untouched and '-n' after '--' is a name rather than a limit. Documented as its own help topic rather than an options row in thirty-nine verbs: '--' is not a verb's option, it is the rule every verb parses by. check-in: 85a1d4bf3f user: dmestas tags: trunk | |
| 11:49 |
zip: flag member names as UTF-8 in both headers
The name bytes were always correct UTF-8 and general-purpose bit 11 was never set, so a conforming reader must decode them as CP437 and a committed 'café.txt' extracted as 'caf├⌐.txt'. Both headers now take the flag from one constant: a reader trusts the central directory for metadata, so setting it on the local header alone would still ship the bug. Set unconditionally, since ASCII is a subset of UTF-8 and one value cannot disagree with itself. Content and the data-descriptor bit are unchanged. check-in: 3caf366005 user: dmestas tags: trunk | |
|
2026-09-19
| ||
| 14:45 |
Release 0.3.24
Closing a protected branch is a protected move; a damaged sync container is an error, not a crash. check-in: 3bcbc1c903 user: dmestas tags: trunk, version-0.3.24 | |
| 14:40 |
container: a damaged container is an error, never a crash or wrong bytes
The first nightly soak flipped one bit in a valid container and brought the process down inside the standard inflate: an integer underflow in its end-of-input bit peek that a truncated stream can arrange, reachable from any peer through every sync body. The decoder is now the tree's own copy of the standard one (Zig 0.16.0, MIT) with the comparison reordered so the stream ends, and its origin noted. With the crash gone the same bytes decoded to 58 bytes reported as good: the flip made a block final, and the zlib footer's Adler-32 was read but never checked, by the decoder or by us. The codec now requires a finished stream and verifies the footer against the output. The exact bytes are a fixed test. check-in: 46fcd75fc3 user: dmestas tags: trunk | |
| 14:40 |
sync: a closed tag on a protected branch is refused
The push gate judged tags by the branch they named, so sym-B and branch=B were refused under any sign while a closed tag, which names a check-in, was admitted: an account that could not push onto trunk could close its tip, and the owners' next commit was refused against a closed leaf with no cause named. A closed tag aimed at a held check-in now resolves that check-in's branch and is refused when the branch is protected, under any sign, saying close or reopen. A release name on the leaf, a close off the branch, and a close of an unheld target stay admitted; a resolver fault still fails closed. check-in: ff30ba16e8 user: dmestas tags: trunk | |
|
2026-09-18
| ||
| 16:31 |
dst: a bitflip inside a config frame owes a repair, as one in a content frame does
The first full nightly soak found seed 22 at 10000 steps: the crash sweep flipped a bit inside a committed config frame, the store's checksum refused to serve it, and the harness reported a config mismatch because only its content-frame path knew that refusal as detection. The config check now routes rot inside the surviving config frame to the repair, and the repair's cut keeps every frame of either kind that ended before the rot, since config frames interleave with content. check-in: 79059346bc user: dmestas tags: trunk | |
| 15:49 |
soak: sweep the DST on the production build too
ReleaseSafe keeps every assert as a detector; the build that ships is ReleaseFast, where only the simulation's own state-replay oracle can catch a bug that appears when the checks are gone. The nightly now runs the same DST sweep on both builds. DST_FAST=0 skips the second. check-in: 4df2fad0e6 user: dmestas tags: trunk | |
| 12:48 |
soak: find the harness binary in the configured cache, never in the repo root
The runners keep Zig's cache outside the workspace, so the find under .zig-cache came up empty and xargs handed ls no arguments: ls listed the repo root and the newest entry, src, was run as the harness. The lookup honours ZIG_LOCAL_CACHE_DIR and an empty find is a build failure. check-in: b56ed097fd user: dmestas tags: trunk | |