-
Notifications
You must be signed in to change notification settings - Fork 28
Add list helper without memory operations #60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
e027d81 to
9a49d30
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No issues found across 3 files
|
Instead of using |
9a49d30 to
1266621
Compare
HeatCrab
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that the original functions and the new helpers share the exact same traversal logic. Would it be better to let the original functions call the new helpers, instead of duplicating the logic?
|
The idea looks good for now. However, in the long run, I wonder if we should consider adopting the Linux kernel approach: embedding the list node within the struct and using container_of(). This would allow us to avoid exposing dual APIs (one with internal allocation and one without). As recent fixes have shown, automatic memory allocation/deallocation can easily lead to oversight and result in memory-related bugs. |
Thanks for your feedback. For this PR, I’ll follow the suggestion from @HeatCrab to consolidate the repetitive API in |
7307a00 to
948d586
Compare
| list_remove_node(list, target); | ||
|
|
||
| prev->next = target->next; | ||
| void *data = target->data; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only free and return data operations are kept in the below section.
|
|
||
| node->data = data; | ||
| node->next = list->tail; | ||
| node->next = NULL; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An initialized node should represent a standalone element; its next pointer must be set to NULL.
You can refine here to consolidate. |
Previously, list_pushback() and list_remove() were the only list APIs available for data insertion into and removal from the list by malloc a new and free target linkage node. The memory overhead becomes a critical issue for rapid API usage. This change adds insertion and removal helpers that operate on linkage nodes instead of calling malloc/free, simplifying linkage node reuse and reducing allocation overhead.
To reuse test suite, test_lib.c is renamed as test_utils.c that consolidate all utilities and helpers. Add a unit test for list_pushback_node() and list_remove_node().
The traversal logic in list_pushback() and list_remove() is identical to the logic already provided by list_pushback_node() and list_remove_node(). This change replaces the duplicated code with calls to these helpers, reducing code duplication.
948d586 to
91dc543
Compare
list_pushback()andlist_remove()allocate and free linkage nodes internally. This behavior prevents callers from reusing linkage nodes and also introduces extra time overhead when these APIs are used frequently.This change introduces two new APIs with the same semantics as the original ones, but without calling malloc() or free() on the linkage nodes. These no-allocation variants allow callers to reuse pre-allocated linkage nodes and reduce the allocation overhead in hot paths.
Summary by cubic
Added no-allocation list helpers for pushback and remove to let callers reuse pre-allocated nodes and avoid malloc/free overhead in hot paths.
New Features
Refactors
Written for commit 91dc543. Summary will update automatically on new commits.