Closing the last hole in the substrate: `CUBE_OP_ENUM` and `CUBE_OP_RANGE`
returned `key | len | value`, so a kernel- or daemon-backed store's
`entries_flagged`/`range_flagged` could only answer from the trait's default —
"no class" for every record in the store. Both walks now return the flag scan's
frame, class included, and both stores answer for real.
`Command::List` and `Command::Range` print it, because the record has one: a
listing that reported only lengths is what made a caller open the store to find
out what it was looking at. That is also what keeps the kernel's listing and
userspace's comparable in the same words, which `verify-enum` and
`verify-range` are built on.
Three parsers had to follow, and each was found by a test rather than by
reading:
* `CubeArgs`'s walk decoder in `cube-kernel` read the length at the wrong
offset — caught by asserting the class of one record and none for its
neighbours, so a decoder that read the wrong two bytes shows up as the
wrong *record* rather than as a length that happens to be right;
* the client's `listed` split a line on " [" and parsed the head, which is
now `<coord> flags=0xNNNN`, so every listing came back EMPTY rather than
failing — a parse that silently drops what it cannot read is the worst
version of this;
* the front-end gate looked for `root:799,0,0 [100B]`.
`verify-frontend` now asserts the class in a *listing* as well as in a point
read, which is the asymmetry the hole was made of: one store, two answers about
the same record.
luulu
6c6b9ba1b1