Repository navigation
nohup: move the C.dup2 call behind a .c.v wrapper - #252
Merged
Merged
Conversation
V no longer permits a C call directly in a pure .v file, so src/nohup/nohup.v calling C.dup2 at line 73 fails the prod build with 'C code will not be allowed in pure .v files'. The declaration already lived in nohup.c.v, so this adds a wrapper there and calls that instead, which is the boundary the compiler now expects. This is why ubuntu-prod-build has been red, and it is unrelated to the PR that surfaced it: nohup has been building only because the local compiler is older than the one CI builds from master, and that difference is worth stating because a build that fails only on the newer compiler looks exactly like a regression in the change under review. Verified on linux, macos, vinix and windows, and the runtime behaviour of nohup is unchanged.
metif12
added a commit
to metif12/coreutils
that referenced
this pull request
Oct 17, 2026
common/dd/dd.v called C.write() directly and declared `fn C.write` in the
same pure .v file. The pinned V rejects that outright:
common/dd/dd.v:219:4: error: C code will not be allowed in pure .v files,
please move it to a .c.v file instead
This is the same defect and the same fix as vlang#252 for nohup, which already
landed: the C declaration and the call to it have to sit on opposite sides
of the .c.v boundary. So common/dd/dd.c.v now holds the declaration plus a
pub write_fds wrapper, and dd.v calls that wrapper.
Kept the `unsafe` block at the call site unchanged. It is there for
`data.data`, not for the C call, and moving it would be a behavioural
change this bug fix does not need.
Verified: dd builds and `hello world | dd` still reports 15 bytes copied
through the new wrapper, and v fmt -verify is clean on both files. The
rejection itself is not reproducible on the compiler available here, which
still permits C calls in a .v file; it comes from the pinned CI revision.
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
2 participants
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.
V no longer permits a C call directly in a pure
.vfile, sosrc/nohup/nohup.vcallingC.dup2at line 73 fails the prod build withC code will not be allowed in pure .v files, please move it to a .c.v file instead.The declaration already lived in
nohup.c.v, so this adds a wrapper there and calls that instead — the boundary the compiler now expects.This is why
ubuntu-prod-buildhas been red. It is unrelated to PR #237, which is where it surfaced:nohuphas been building only because my local compiler is older than the one CI builds frommaster, and that difference is worth stating plainly, because a build that fails only on the newer compiler looks exactly like a regression in whatever change is under review.Verified on linux, macos, vinix and windows. Runtime behaviour of
nohupis unchanged — I built the pre-change binary fromupstream/mainand confirmed both versions panic identically onnohup --version, so the panic is pre-existing and not something this introduces.