Skip to content

cgen: define L_tmpnam on glibc instead of including <stdio.h> (follow-up to #28121) - #28122

Open
medvednikov wants to merge 1 commit into
masterfrom
cgen-define-ltmpnam-no-stdio-include
Open

cgen: define L_tmpnam on glibc instead of including <stdio.h> (follow-up to #28121)#28122
medvednikov wants to merge 1 commit into
masterfrom
cgen-define-ltmpnam-no-stdio-include

Conversation

@medvednikov

Copy link
Copy Markdown
Member

Follow-up to #28121, which fixed the glibc error: 'L_tmpnam' undeclared here build 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_tmpnam

V 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_H in <bits/stdio_lim.h>), and L_tmpnam is the only one of them that <stdio.h> itself uses in a declaration:

extern char *tmpnam (char[L_tmpnam]) __THROW __wur;

FILENAME_MAX, TMP_MAX, FOPEN_MAX are only #defines for user code — nothing in the tree or the generated C references them — so L_tmpnam is the one that must exist when a <stdio.h> gets pulled in later by a module header (sqlite3.h, gc.h, …).

#if defined(__GLIBC__) || defined(__GNU_LIBRARY__)
#ifndef L_tmpnam
#define L_tmpnam 20
#endif
#endif

20 is 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 -Werror redefinition diagnostic.

v3 (new compiler)

Verified the three #28121 issues are not a problem for the v3 backend:

  • glibc L_tmpnam: v3 reuses this same c_headers block via manual_stdlib_c_headers() (embeds cheaders.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 a preamble_test.v assertion to lock this in.
  • v doc -theme-dir / v missdoc -e: vdoc and missdoc are shared tools; v3 does not reimplement them.
  • -e argument passthrough: v3 has no argument parser of its own — the launcher handling lives in pref.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_tmpnam define 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-linux job (it builds vbug-report.v, the original failing case).

🤖 Generated with Claude Code

…-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>
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@github-actions

Copy link
Copy Markdown

Master CI failures for cbe0fe208a1569091f9dc9b754f0cbde14ef878e

Found 4 failed workflow runs. Detailed diagnostic comments follow.

@github-actions

Copy link
Copy Markdown

Failed workflow: CI macOS

Run 32190095484; 1 failed job(s).

clang-macos (macos-14) — job 95882328072

Could not download this job log.

@github-actions

Copy link
Copy Markdown

Failed workflow: CI Windows MSVC

Run 32190095438; 1 failed job(s).

msvc-windows — job 95882327819

Could not download this job log.

@github-actions

Copy link
Copy Markdown

Failed workflow: CI Windows TCC

Run 32190095359; 1 failed job(s).

tcc-windows — job 95882327904

Could not download this job log.

@github-actions

Copy link
Copy Markdown

Failed workflow: CI Windows GCC

Run 32190095460; 1 failed job(s).

gcc-windows — job 95882327950

Could not download this job log.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant