-
-
Notifications
You must be signed in to change notification settings - Fork 435
Refactor char** array to string collection in upssched and other code #3111
Copy link
Copy link
Open
Labels
C-strIssues and PRs about C/C++ methods, headers and data types dealing with strings and memory blocksIssues and PRs about C/C++ methods, headers and data types dealing with strings and memory blocksrefactor/fightwarnPR or issue proposal to improve code maintainability without functional changes, or to fix warningsPR or issue proposal to improve code maintainability without functional changes, or to fix warnings
Milestone
Description
Metadata
Metadata
Assignees
Labels
C-strIssues and PRs about C/C++ methods, headers and data types dealing with strings and memory blocksIssues and PRs about C/C++ methods, headers and data types dealing with strings and memory blocksrefactor/fightwarnPR or issue proposal to improve code maintainability without functional changes, or to fix warningsPR or issue proposal to improve code maintainability without functional changes, or to fix warnings
Type
Fields
Give feedbackNo fields configured for issues without a type.
PRs like #3097 and #3095 introduced some copy-pasta creep into NUT code base (with
collect_stringandanalyze_mapping_usagemethods in particular), which would do well to be refactored into some shared implementation of what is currently nuancely-different code.Maybe we can refactor the data structure involved here, to merge code with common
str_add_unique_tokenetc. methods?Code parked in PR #2476 can also be useful here, modulo that use-cases to be refactored also want to add separators - so another argument to something like that
str_concat()method. Currently the in-tree code uses a sentinel NULL to end off the array of strings, andstr_concat()uses a count argument with varargs to limit the stack walk. Not sure if one approach is fully better over the other, or they just fit different use-cases.