Repository navigation
Allocate dmlist_create() on the caller's own DMOD_CURRENT_ALLOCATOR - #11
Merged
Merged
Conversation
dmlist_create() used to require every caller to pass its own module name explicitly. Rename the underlying Built-in API to dmlist_create_ex(module_name) and add dmlist_create() back as a macro that forwards to it with DMOD_CURRENT_ALLOCATOR (see dmod's dmod_sal.h) - the identity of whoever calls it, whether that's a module or a system-side library. This matches how Dmod_Malloc/Dmod_Free already attribute allocations, and callers that do need to attribute a list to someone other than themselves can still call dmlist_create_ex() directly. Requires dmod's DMOD_CURRENT_ALLOCATOR system-side support (see the companion dmod PR).
1 of 3 tasks
JohnAmadis
pushed a commit
to choco-technologies/dmvfs
that referenced
this pull request
Sep 19, 2026
dmlist_create() is now a macro that forwards to dmlist_create_ex() with the caller's own DMOD_CURRENT_ALLOCATOR instead of taking an explicit module name (see choco-technologies/dmlist#11) - update the one call site in tests/main.c accordingly. Verified: full CMake build of the fs_tester test binary against the now-merged dmod (develop) and dmlist's fix branch compiles and links cleanly.
1 of 2 tasks
JohnAmadis
pushed a commit
to choco-technologies/dmod-boot
that referenced
this pull request
Sep 19, 2026
dmvfs.c includes dmfsi.h, whose inline helpers (dmfsi_strndup, dmfsi_path_create, ...) use the plain Dmod_Malloc/Dmod_Free macros - these expand into whatever translation unit includes the header, so dmvfs's own compilation now needs DMOD_CURRENT_ALLOCATOR defined too, not just dmfsi's: error: DMOD_CURRENT_ALLOCATOR must be defined manually on the system side choco-technologies/dmvfs already fixed this on its develop branch (PR #55, same coordinated rollout as the previous two bumps), but that same PR range also lands PR #56, which updates dmvfs's call site for dmlist's dmlist_create() - that function changed from taking an explicit module-name argument to a zero-arg macro that pulls DMOD_CURRENT_ALLOCATOR in automatically (choco-technologies/dmlist#11, from the same rollout). Taking the dmvfs fix without the matching dmlist bump would trade one compile error for another (argument-count mismatch), so bump both together. Both bumps verified ancestor-safe via git merge-base --is-ancestor; nothing else in this repo's submodule tree calls dmlist_create() directly.
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.
Summary
Companion PR to choco-technologies/dmod#307, which requires
DMOD_CURRENT_ALLOCATORto be defined on the system side too (it used to default toNULL/anonymous there).dmlist_createBuilt-in API todmlist_create_ex(module_name)(implementation insrc/dmlist.c, declaration ininclude/dmlist.h) - same behavior, explicit-owner allocation.dmlist_create()back as a macro:#define dmlist_create() dmlist_create_ex(DMOD_CURRENT_ALLOCATOR). Every caller - an application module, a library module, or a system-side library - now gets its list allocated under its own identity automatically, the same wayDmod_Malloc/Dmod_Freealready work, instead of having to pass its own name explicitly.tests/test_simple.candREADME.mdexamples to the new zero-argumentdmlist_create()call.tests/CMakeLists.txt: addeddmod_set_current_allocator(test_simple)so the raw test executable (not built throughcreate_library_makefile()) satisfiesdmod_sal.h's new requirement.DMOD_CURRENT_ALLOCATOR="dmlist"compile definition into the committed rootMakefile(used for Make-based builds) - this file already appears to have drifted from what CMake would currently regenerate (missingsrc/dmlist_registrations.c), so this PR makes only the one targeted addition rather than a full regeneration.Depends on
This needs choco-technologies/dmod#307 merged first - until then, building this against
dmod'sdevelopbranch will hit the new#errorindmod_sal.hunlessDMOD_CURRENT_ALLOCATORis otherwise defined.Test plan
test_simpleagainst a local copy of the dmod branch from PR #307 (-DFETCHCONTENT_SOURCE_DIR_DMOD=...) - compiles cleanly,DMOD_CURRENT_ALLOCATOR="dmlist"correctly injected.test_simpleagainst unmodifieddmod) that the pre-existing__dmod_inputs_end/__dmod_outputs_endlink failure for that test target is not caused by this change - it reproduces identically without any of these changes.🤖 Generated with Claude Code
https://claude.ai/code/session_01E7dx6Rd66adYqPjRLyE1GM
Generated by Claude Code