cgen: define L_tmpnam on glibc instead of including <stdio.h> (follow-up to #28121) - #28122
Open
medvednikov wants to merge 1 commit into
Open
cgen: define L_tmpnam on glibc instead of including <stdio.h> (follow-up to #28121)#28122medvednikov wants to merge 1 commit into
medvednikov wants to merge 1 commit into
Conversation
…-up to #28121) #28121 fixed the glibc `L_tmpnam undeclared` build error (#28108) by re-adding `#include <stdio.h>` on the glibc prelude path. V aims to pull in as few system headers as possible, so define the macro directly instead of including the header. L_tmpnam is the one stdio limit macro that glibc's <stdio.h> uses in a prototype (`char *tmpnam(char[L_tmpnam])`), and glibc only defines it while <stdio.h> is being processed. Its value (20) is a stable glibc constant, and a later identical redefinition by glibc is a no-op, so defining it up front keeps a <stdio.h> pulled in by a module header (sqlite3.h, gc.h, ...) compiling, with no extra include. Add regression tests for the v1 prelude and for the v3 backend, which reuses the same c_headers block via manual_stdlib_c_headers(). The other two issues from #28121 are not v3 specific: vdoc/missdoc are shared tools, and the launcher argument handling lives in pref.parse_args_for_launcher(), which every backend goes through. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Master CI failures for
|
Failed workflow: CI macOSRun clang-macos (macos-14) — job
|
Failed workflow: CI Windows MSVCRun msvc-windows — job
|
Failed workflow: CI Windows TCCRun tcc-windows — job
|
Failed workflow: CI Windows GCCRun gcc-windows — job
|
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
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.
Follow-up to #28121, which fixed the glibc
error: 'L_tmpnam' undeclared herebuild failure (#28108) by re-adding#include <stdio.h>on the glibc prelude path.V tries to include as few system headers as possible, so this replaces that include with a direct macro definition.
Why just
L_tmpnamV declares the stdio functions manually and does not
#include <stdio.h>. glibc only defines the stdio limit macros while<stdio.h>is being processed (they sit behind#ifdef _STDIO_Hin<bits/stdio_lim.h>), andL_tmpnamis the only one of them that<stdio.h>itself uses in a declaration:FILENAME_MAX,TMP_MAX,FOPEN_MAXare only#defines for user code — nothing in the tree or the generated C references them — soL_tmpnamis the one that must exist when a<stdio.h>gets pulled in later by a module header (sqlite3.h,gc.h, …).20is a stable glibc constant, and glibc's own definition is#define L_tmpnam 20(identical), so if<stdio.h>is later processed its redefinition is a no-op — no-Werrorredefinition diagnostic.v3 (new compiler)
Verified the three #28121 issues are not a problem for the v3 backend:
c_headersblock viamanual_stdlib_c_headers()(embedscheaders.v), so it inherits the define on its system-libc path; its headerless path never includes<stdio.h>at all (it forward-declares the functions it uses). Added apreamble_test.vassertion to lock this in.v doc -theme-dir/v missdoc -e:vdocandmissdocare shared tools; v3 does not reimplement them.-eargument passthrough: v3 has no argument parser of its own — the launcher handling lives inpref.parse_args_for_launcher(), which every backend goes through.Tests
vlib/v/gen/c/cheaders_manual_stdlib_decls_test.v: asserts the glibc guard +L_tmpnamdefine are in the prelude.vlib/v3/gen/c/preamble_test.v: asserts the v3 backend inherits the define.Both pass locally; the actual glibc compile is exercised by the Linux
tools-linuxjob (it buildsvbug-report.v, the original failing case).🤖 Generated with Claude Code