fix(atomic): make Windows/MSVC db build compile clean - #117
Merged
Conversation
Two independent MSVC breaks in the Windows atomics path: 1. os_atomic.c's Windows Interlocked tier casts through interlocked_val (LONG volatile *) but that macro was only defined in mut_win32.c, so the type was undeclared in this TU -> C2065/C2064. Define it locally in the same self-contained way mut_win32.c does. 2. db.h's legacy unprefixed 4BSD dbm(3) aliases (store, fetch, firstkey, nextkey, dbminit, dbmclose, delete) are object/function-like macros. In a C++ translation unit (the cxx_*.cpp files in db.vcxproj) MSVC's <atomic> is pulled in transitively and its std::atomic<>::store member collides with the 'store' macro -> C4003/C2059/C2039/C2086. These names are a C-only historic interface (delete was already guarded); guard the whole set with #if !defined(__cplusplus). Fixed in the template src/dbinc/db.in and regenerated build_windows/db.h via dist/s_windows.
MSVC's C++ standard library transitively includes <atomic> in every C++ translation unit (e.g. the cxx_*.cpp sources in db.vcxproj). dbinc/atomic.h defines a function-like macro atomic_init(p, val) whose name exactly matches the standard std::atomic_init free function template, so the macro rewrote that declaration and broke <atomic> (C2059/C2086 redefinition of std::__os_atomic_init). Berkeley DB only calls atomic_init() from C sources, so define the macro only for C.
Coccinelle convention checksNo new violations. ✅ Resolved since baseline (2) -- update dist/cocci/baseline.txt to lock these in. |
ABI diff vs
|
os_atomic.c holds the Windows Interlocked implementations of __os_atomic_* but was never listed in the Windows VS project files (it is in the Unix Makefile.in). The db library therefore linked with unresolved externals (__os_atomic_read/_inc/_dec/_cas, referenced by mut_win32.c, mp_*.c, lock.c, txn.c, ...). Add it next to os_alloc.c in the VS10 (.vcxproj) and VS8 (.vcproj) db and db_small projects.
The async-I/O layer (__os_aio_create/submit/reap/destroy/available/ ctx_available in os_aio.c, referenced by mp_bh.c and mp_region.c) was added to the Unix Makefile.in but never to the Windows VS project files, leaving the db library with unresolved externals at link time. Add os_aio.c (the generic layer + synchronous fallback, always compiled) plus the os_aio_iocp.c and os_aio_pool.c backends (empty TUs unless HAVE_IOCP / HAVE_AIO_THREADPOOL are configured) to the VS10 and VS8 db/db_small projects, mirroring the Unix build.
gburd
added a commit
that referenced
this pull request
Jul 31, 2026
fix(atomic): make Windows/MSVC db build compile clean
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.
Problem
The
dblibrary fails to build under MSVC (GitHubwindows msbuildCI). Investigation on a Windows/ARM64 host (MSVC 17 VS2022 + MSVC 18 VS2026) surfaced four real, independent Windows-build breaks in the atomics/AIO area.1.
interlocked_valundeclared inos_atomic.c(compile, C)The Windows Interlocked tier casts
&db_atomic_t::valuetoLONG volatile *through theinterlocked_valmacro, defined only insrc/mutex/mut_win32.c. Inos_atomic.cit was undeclared, so(interlocked_val)(&p->value)parsed as a function call:2. macro collisions with MSVC C++
<atomic>(compile, C++)db.vcxprojcompileslang/cxx/*.cppas C++. MSVC's C++ standard library transitively pulls<atomic>into every C++ TU. Two Berkeley DB macros then rewrote standard-library identifiers inside<atomic>:db.h's legacy 4BSDdbm(3)alias#define store(a, b) ...clobberedstd::_Atomic_storage<>::store->C4003/C2059.dbinc/atomic.h's#define atomic_init(p, val) ...clobbered thestd::atomic_initfree-function template ->C2059/C2086 redefinition of std::__os_atomic_init.3.
os_atomic.cmissing from the Windows projects (link)The atomic implementations live in
os_atomic.c, which is in the UnixMakefile.inbut was never added to the Windows VS project files ->LNK2019/LNK2001 unresolved external symbol __os_atomic_read/_inc/_dec/_cas/_init.4.
os_aio*missing from the Windows projects (link)Same class of gap: the async-I/O layer (
__os_aio_*inos_aio.c, referenced bymp_bh.c/mp_region.c) was added to Unix but not to Windows ->LNK2019 unresolved external symbol __os_aio_create/_submit/_reap/_destroy/_ctx_available.Root cause
store/fetch/firstkey/nextkey/dbminit/dbmclose/deleteare the historic C-only 4BSDdbminterface (deletewas already#if !defined(__cplusplus)-guarded because it is a C++ keyword).atomic_initis the C11 / C++<atomic>reserved spelling. Neither is ever called from C++ here. Andos_atomic.c/os_aio*.cwere added to the Unix build without updating the hand-maintained Windows project files.Fix
src/os/os_atomic.c: defineinterlocked_vallocally in the Windows tier (guarded, same self-contained pattern asmut_win32.c).src/dbinc/db.in(+ regeneratedbuild_windows/db.hviadist/s_windows): wrap the whole unprefixed 4BSDdbmmacro set in#if !defined(__cplusplus), extending the existingdeleteprecedent.src/dbinc/atomic.h: define theatomic_initcompatibility macro only for C.build_windows/VS10/{db,db_small}.vcxprojandbuild_windows/VS8/{db,db_small}.vcproj: addos_atomic.cand theos_aio.c/os_aio_iocp.c/os_aio_pool.csources (the latter two are empty TUs unlessHAVE_IOCP/HAVE_AIO_THREADPOOLare configured), mirroring the Unix build.No behavior change for C consumers; C++ TUs never used any of these macros.
Validation
windows msbuildCI (x64, v143): green on the final commit.os_atomic.c(/TC) andcxx_db.cpp(/TP) compile with 0 errors; a full manual compile+link of thedbproject sources produceslibdb.dllwith 0 unresolved externals (the__os_atomic_*and__os_aio_*symbols now resolve).../dist/configure && make): clean.--enable-cxx: clean (14 cxx objects — confirms no C++ path needs the guarded macros).libdb.so).Depends on the regenerated Windows headers from #114 (merged); rebased onto master so this PR is only the atomics/AIO Windows-build delta.