Repository navigation
Conversation
Reads and writes terminal attributes, and is the last unimplemented tool. Verified against GNU 9.4 in a pty: all 13 cases byte-identical, including the non-tty error path. -a matches on all ten lines, -g on all four flag words and 32 control characters, and size, sane, -icanon, icanon, echo, -echo and the -F/--file forms all match. Four things were measured rather than recalled, and each was a bug: V's termios.Termios has a different layout from glibc's struct termios. c_cc sits at offset 20 instead of 17 because the compiler pads after c_line. An offsetof probe showed glibc reporting c_lflag 0x105073 where V read 0x8a3b, so every control character and the top byte of every flag word was wrong. This port includes termios.h and uses C.termios directly. The \ format does not apply to a C-typed field. A probe printed c_iflag=1280 and hex: iflag=1280, identical with the format silently ignored, which made -g wrong by a whole nibble. Each word is cast to u32 first. The flag polarity in -a is the opposite of what the option syntax suggests: a bare name means the flag is set and a leading dash means it is clear. The wrap width is 79 not 76, the input-mode order is ixon, ixoff, iuclc, ixany, and several bit values differ from recall, so every constant comes from a C probe printing the preprocessor values. Not implemented, stated rather than hidden: the control settings rows, columns, cols, drain and flush, the evenp/oddp/parity aliases and the special-character assignment forms. The suite is stty_nix_test.v because termios.h does not exist on Windows tcc, and V cannot generate C for a test target, so the Linux CI job is what runs it.
The repo measures itself with the unit tests it writes for itself. This adds the other measurement: the tests GNU writes for its own implementation, run against ours. The pass rate of that suite is the number that tells us where we actually stand, and it is not a number this repo has ever had. The flow is the one uutils/coreutils uses, and is not original work: fetch the release tarball, configure it, copy lib/stdckdint.in.h over lib/stdckdint.h, build, point tests/local.mk at our bin/ instead of GNU's own src/, and run make check. Two things had to be worked out, and both cost a build cycle each: **Building GNU at all.** The tree ships lib/stdckdint.in.h, gnulib's replacement for the C23 header that gcc 13 on Ubuntu 24.04 does not provide, but the make rule that copies it into place never fires, so lib/malloca.c dies on `#include <stdckdint.h>`. Copying it by hand is the whole fix - the file has no substitution markers. The release tarball is used rather than the git sources because it ships configure and tests/ pre-generated, so no autoreconf, gperf, bison or texinfo is needed. **Pointing the tests at our binaries.** This is done in two places, because the tests find their subject through two independent mechanisms: the PATH= line in tests/local.mk, and `path_prepend_ ./src`, which most tests call to prepend the build directory. Patching only the first leaves every test silently measuring GNU - I measured 417 "passes" that were GNU's, and it took a control run against GNU's own binaries to prove the harness was sound before trusting any number. Results are filtered to the tools actually present in bin/, because a test for a tool nobody built fails with a missing-command error that says nothing about this implementation. Those are counted as not-run rather than dropped, so the report never hides how much of the suite was measured. The job does not gate the build. It is informational until the pass rate means something, and the log is uploaded as an artifact so the failures are readable rather than inferred. Local run against 43 cross-compiled tools: 0 pass, 2 fail, 72 skip, 4 not-run. The skips are legitimate - no gdb, no root, no ACLs - and the two failures are real and actionable: our `env` rejects `---` and `-u` where GNU accepts them, and mishandles `env --` and `env -u 'a=b'`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ci: run the GNU coreutils test suite against our binaries
The repo measures itself with the unit tests it writes for itself. This adds the other measurement: the tests GNU writes for its own implementation, run against ours. The pass rate of that suite is the number that says where we actually stand, and it is not a number this repo has ever had.
The flow is the one uutils/coreutils uses, and is not original work: fetch the release tarball, configure it, copy
lib/stdckdint.in.hoverlib/stdckdint.h, build, pointtests/local.mkat ourbin/instead of GNU's ownsrc/, and runmake check.Two things had to be worked out, and each cost a build cycle:
Building GNU at all. The tree ships
lib/stdckdint.in.h, gnulib's replacement for the C23 header that gcc 13 on Ubuntu 24.04 does not provide, but the make rule that copies it into place never fires, solib/malloca.cdies on#include <stdckdint.h>. Copying it by hand is the whole fix — the file has no substitution markers in it. The release tarball is used rather than the git sources because it shipsconfigureandtests/pre-generated, so no autoreconf, gperf, bison or texinfo is needed.Pointing the tests at our binaries. This is done in two places, because the tests find their subject through two independent mechanisms: the
PATH=line intests/local.mk, andpath_prepend_ ./src, which most tests call to prepend the build directory. Patching only the first leaves every test silently measuring GNU — I measured 417 "passes" that were GNU's, and it took a control run against GNU's own binaries to prove the harness was sound before trusting any number it produced.Results are filtered to the tools actually present in
bin/, because a test for a tool nobody built fails with a missing-command error that says nothing about this implementation. Those are counted as not-run rather than dropped, so the report never hides how much of the suite was measured.The job does not gate the build. It is informational until the pass rate means something, and the log is uploaded as an artifact so the failures are readable rather than inferred.
Local run against 43 cross-compiled tools: 0 pass, 2 fail, 72 skip, 4 not-run. The skips are legitimate — no gdb, no root, no ACLs. The two failures are real and actionable: our
envrejects---and-uwhere GNU accepts them, and mishandlesenv --andenv -u a=b.The suite runs bare
make check, so anything it measures runs against whatever PATH provides too. That is how a test for a tool absent frombin/gets counted as not-run — but it also means a tool that is inbin/and is wrong falls back to nothing and fails, which is the behaviour wanted.