Made ThreadX object names const-qualifiable behind an option - #761
Merged
Merged
Conversation
Fixes eclipse-threadx#61 Object names were exposed as writable pointers throughout the kernel API, which rejected string literals in C++ and let callers modify retained names. The information services also returned names through writable double pointers. Create services, control blocks, information services, modules, and trace registration now preserve const qualification. TX_LEGACY_NON_CONST_NAMES restores the prior declarations for one release cycle. The FreeRTOS adapter retains its writable return type with a MISRA C:2012 Rule 11.8 cast because that signature is part of the FreeRTOS API. All five ThreadX configurations passed 515/515 tests, and all five SMP configurations passed 580/580. Legacy normal and SMP builds, module library and module-manager checks, the C++ API check, and 3/3 FreeRTOS tests passed. Coverage was not collected because gcovr is unavailable. Co-authored-by: Tilen Majerle <tilen@majerle.eu> Assisted-by: Codex (gpt-6-astra) <noreply@openai.com>
fdesbiens
marked this pull request as ready for review
September 28, 2026 16:52
Three files conflicted, all of them on the AI disclosure comment and none on code. The two tx_thread_create.c sources differ only in the comment character. txm_module_manager_dispatch.h had collected two disclosure lines on this branch and seven on dev, naming three products between them. Two more files ended up with two disclosure lines each and no conflict marker, because this branch adds the line in block-comment form to files dev had already normalised to a line comment: tx_trace.h and the thread basic execution test. Each of the five now carries the accepted line once, written the way the rest of the tree writes it. Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
Object names became TX_NAME_CONST across the kernel on this branch. Code that reached dev afterwards still declares them writable, so the merged tree does not build: _txm_module_manager_object_name_compare takes the object's name as CHAR *, which discards the qualifier at all eight call sites in txm_module_manager_object_pointer_get_extended.c, and the block pool parameters test stubs _txe_block_pool_create, _txe_byte_pool_create and _txe_queue_create with a writable name pointer, which conflicts with the declarations they stand in for. All four now take TX_NAME_CONST CHAR *. The compare function only reads through that pointer. Host 113/113 and SMP 118/118, both with zero warnings. Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
fdesbiens
force-pushed
the
const-object-names
branch
from
September 28, 2026 17:21
6ea574d to
59419c9
Compare
This was referenced Sep 28, 2026
_tx_trace_object_register reads the object's name through TX_CHAR_TO_UCHAR_POINTER_CONVERT. Every form of that macro but one casts the qualifier away without saying so, so only the MISRA build reports the const name being passed to a shim that takes CHAR *, and it reports it as an error. The conversion now takes TX_NAME_CONST CHAR * and returns const UCHAR *, and the registration loop walks the name through its own const pointer with a matching TX_CONST_UCHAR_POINTER_ADD. Those two call sites are the only users of the conversion in the kernel, so nothing else has to change and nothing launders const to make it compile. Only the trace configurations compile that function, so a build of the default configuration alone proves nothing here. All seven host configurations and all five SMP configurations build with zero warnings and pass: 113/113 and 100/100 on the host, 118/118 on SMP. Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
fdesbiens
force-pushed
the
const-object-names
branch
from
September 28, 2026 17:42
59419c9 to
875ca36
Compare
TX_NAME_CONST changes the type of a public struct field, so application code that copies an object name into a writable CHAR * stops compiling. That is a reasonable thing to ask of a minor release and not of a patch one, and the switch was the wrong way round for shipping it now: every integrator was opted in, and the escape hatch was theirs to find after their build broke. The macro is now TX_ENABLE_CONST_NAMES and it defaults to off, so a build that says nothing gets exactly the types it got before. Everything the const pass touched stays as it is and comes alive when the option is set. That includes the FreeRTOS adapter, whose pcTaskGetName holds the name it retrieves in a TX_NAME_CONST pointer rather than a const one, so it matches whichever declaration tx_thread_info_get has. The cast on the way out stays: FreeRTOS exposes task names through a writable pointer type, and that is the Rule 11.8 deviation the comment describes. Default: all seven host configurations and all five SMP configurations build with zero warnings and pass, 113/113 and 100/100 on the host, 118/118 on SMP, plus 3/3 FreeRTOS. With TX_ENABLE_CONST_NAMES set, the host default and both MISRA configurations, the SMP trace configuration and the FreeRTOS adapter build with zero warnings and pass. Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
fdesbiens
force-pushed
the
const-object-names
branch
from
September 28, 2026 17:50
875ca36 to
22dd28a
Compare
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
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.
Fixes #61
Object names are exposed as writable pointers throughout the kernel API, which rejects string literals in C++ and lets callers modify retained names. Information services return those names through writable double pointers.
Create services, control blocks, information services, modules and trace registration now preserve const qualification, behind
TX_ENABLE_CONST_NAMES. The option defaults to off, so a build that says nothing gets exactly the types it got before. It is opt-in rather than opt-out because it changes the type of a public struct field: application code that copies a name into a writableCHAR *stops compiling, which is a reasonable thing to ask of a minor release and not of a patch one. The FreeRTOS adapter holds the name it retrieves in aTX_NAME_CONSTpointer so it matches whichever declarationtx_thread_info_gethas, and keeps its writable return type through an explicit MISRA C:2012 Rule 11.8 deviation, because that signature is part of the FreeRTOS API.Two things the const build reaches that the default does not.
_txm_module_manager_object_name_compareand the_txe_*_createstubs in the block pool parameters test took the name asCHAR *, and both arrived after this branch was written.TX_CHAR_TO_UCHAR_POINTER_CONVERTis used in exactly two places, both of them reading an object name in_tx_trace_object_register, and every form of that macro but the MISRA one casts the qualifier away without saying so; the conversion is now const in and const out, so nothing launders const to make the build pass.Default build: all seven host configurations and all five SMP configurations build with zero warnings and pass -- 113/113 on five host configurations, 100/100 on the two MISRA builds, 118/118 on SMP, and 3/3 FreeRTOS. With
TX_ENABLE_CONST_NAMESset, the host default and both MISRA configurations, the SMP trace configuration and the FreeRTOS adapter build with zero warnings and pass. Only the trace configurations compile_tx_trace_object_registerand only the MISRA ones report a discarded qualifier, so the default configuration alone proves neither.Matching changes are prepared in USBX and GUIX, and the user guide has already merged. Each of them describes the qualification as the default and needs the same switch. NetX Duo's
NX_PACKET_DEBUGmacro assigns a thread name into a writableCHAR *field, which the option surfaces; it is behindNX_ENABLE_PACKET_DEBUG_INFOand no default configuration builds it. FileX and LevelX need no changes.