Skip to content

Commit c90ff46

Browse files
builtin: fix GetFinalPathNameByHandleW declaration for TCC on Windows
TCC''s bundled windows.h does not include fileapi.h, so GetFinalPathNameByHandleW had no C declaration in scope when TCC compiled any program that pulled in builtin. TCC (in C99 mode) treats implicit function declarations as hard errors. Use a compiler-conditional declaration: - Under TCC, mark it @[c_extern] so V emits a forward declaration (guarded by #ifndef). TCC''s fileapi.h cannot be included directly because it pulls in apiset.h, which TCC does not bundle, so supplying the declaration from V is the only viable route. - Under GCC/MSVC, declare it bare (no @[c_extern]) so V emits no declaration and the call resolves against the SDK header that windows.h pulls in transitively. Emitting a V extern here would conflict with the SDK''s `DWORD WINAPI` signature (DWORD is unsigned long, not u32) and fail with -Werror. The whole block is guarded by $if windows {} so the symbol is not compiled into Linux/macOS builds, where it does not exist. Verified: generated C contains the extern only for the TCC backend and omits it for GCC; `vlib/os/` tests pass (24/24) on Windows with GCC. Co-Authored-By: WOZCODE <contact@withwoz.com>
1 parent 6c4d26f commit c90ff46

1 file changed

Lines changed: 12 additions & 1 deletion

File tree

vlib/builtin/cfns.c.v

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -295,7 +295,18 @@ fn C.CreateFile(lpFilename &u16, dwDesiredAccess u32, dwShareMode u32, lpSecurit
295295
fn C.CreateFileW(lpFilename &u16, dwDesiredAccess u32, dwShareMode u32, lpSecurityAttributes &u16, dwCreationDisposition u32,
296296
dwFlagsAndAttributes u32, hTemplateFile voidptr) voidptr
297297

298-
fn C.GetFinalPathNameByHandleW(hFile voidptr, lpFilePath &u16, nSize u32, dwFlags u32) u32
298+
$if windows {
299+
$if tinyc {
300+
// TCC's bundled windows.h does not include fileapi.h (which itself
301+
// pulls in apiset.h that TCC lacks), so the function has no
302+
// declaration in scope; @[c_extern] makes V emit one without
303+
// conflicting with the SDK header that GCC/MSVC pull in transitively.
304+
@[c_extern]
305+
fn C.GetFinalPathNameByHandleW(hFile voidptr, lpFilePath &u16, nSize u32, dwFlags u32) u32
306+
} $else {
307+
fn C.GetFinalPathNameByHandleW(hFile voidptr, lpFilePath &u16, nSize u32, dwFlags u32) u32
308+
}
309+
}
299310

300311
fn C.CreatePipe(hReadPipe &voidptr, hWritePipe &voidptr, lpPipeAttributes voidptr, nSize u32) bool
301312

0 commit comments

Comments
 (0)