Repository navigation
Name pointers should be constant #61
Description
Activity
Very good point. I support this as well. Having those C strings non const is a major nuisance, in particular for C++ users. Our code is cluttered with unnecessary casts and #pragma GCC diagnostic ignored "-Wwrite-strings" statements to make the code compile with C++.
Hi All,
We on the RTOS team agree with you - we'd like to make this const. Unfortunately, we can not change the existing API. This change requires lots of documentation work (API definitions/example code/etc.), coding, and testing. This also goes well beyond just ThreadX – all components and add-on protocols would need the same. ThreadX and most of our middleware is going through the re-certification process and this change can't be made right now.
(const) Sorry.
hey @goldscott
Thanks for the quick response.
And I understand the certification part and that you can't make this change right now.As for the rest, let me stress that this only involves updating the documentation on the API declaration (apart from the code, of course). No changes are required in the samples, example code and explanations. In the end this acts a compiler hint and letting the caller know that the callee wont change the content of the string.
Plus this is not a breaking change in the sense that the existing code has to be modified to use the new declaration.
Last thought: I understand that developers want stability (and I count myself among those) but that should never prevent improving things and moving forward. Having said that one can always provide alternative APIs and mark others as obsolete and plan for their removal in X versions.
Please give it another tough or, at least, put it on the backlog for the spring cleaning.
Reacted by Henrik Maier, csrichter, OortJacek, Simen August Tinderholt and nate-plxs@josesimoes we agree with you that we will review this in the future. Close the issue now. Feel free to reopen it or reach out to us if you have additional thoughts or comments. Thanks!
any updates on when this issue will be worked on?
as @josesimoes said, this fix should be backwards compatible with all existing code and examples. It shouldn't break the API for existing users
Hi @csrichter @josesimoes @hwmaier - we are working on this now!
Reacted by José Simões, OortJacek, G-glop, csrichter, Simen August Tinderholt and Gary R. Van Sickle@eclipse-threadx/iot-threadx-committers: Please review the PR mentioned above.
Thank you all for your patience on this one. Five years is far too long for an issue this well argued, and I want to give you a definite answer rather than another deferral.
The short version: we are going to do it. @MaJerle, I am sorry that #414 sat unreviewed until you closed it in April; that was our failure, not yours, and your work will be credited and used as the starting point.
Here is the plan we intend to implement. The name parameters of every
tx_*_create()service becomeconst CHAR *. The name fields inside the control blocks (tx_thread_name,tx_queue_name, and the six others) becomeconst CHAR *as well, because otherwise every create service would have to cast the qualifier away. The name output parameters of the*_info_get()services becomeconst CHAR **._tx_trace_object_register()becomesconsttoo, which lets us delete the(CHAR *)cast thatTX_TRACE_OBJECT_REGISTERperforms today.@billlamiework raised the API stability concern on #414, and he was right to. Two of these changes are genuine source-level breaks: reading a name field straight into a
CHAR *, and passing aCHAR **to an*_info_get()service. To address that we will ship aTX_LEGACY_NON_CONST_NAMESoption intx_user.hthat restores the previous signatures for one release cycle, with a deprecation notice, so that anyone with certification or vendor constraints has a supported way to stay put while they migrate. @gzzi, this is a smaller version of the opt-in you proposed, inverted so that the correct behaviour is the default.We are also going to do it properly rather than only in the kernel, which was @goldscott's point back in 2020. Branches will be prepared for NetX Duo, FileX, USBX, GUIX and LevelX before anything merges, so the ecosystem is never left half-converted. Note that middleware and application code that merely calls
tx_*_create()needs no change at all, since aCHAR *argument converts to aconst CHAR *parameter implicitly.On timing, I have to be straight with you. We are entering a code freeze today for the September release, so this will not land in it. The work starts in early October and is targeted at the December release. The user guide will be updated in the same cycle.
Before we start cutting branches I would like the committers to weigh in. @eclipse-threadx/iot-threadx-committers, please review the plan above, and in particular say now if you object to the two breaking changes or to the shape of the opt-out. @josesimoes, @hwmaier, @csrichter, @MaJerle, @gzzi — comments from your side are very welcome too, especially if you can think of a usage pattern the opt-out would fail to cover.
Reacted by José SimõesReacted by Scott and Guillaume Galeazzi- added a commit that references this issue
on Sep 28, 2026
On every call that has a name in the parameters e.g.
tx_byte_pool_create,tx_timer_create, etc thename_ptrshould beconst CHAR *name_ptrinstead of the currentCHAR *name_ptr.It's not only a GP to give that hint to the compiler but also makes the code usable in C++ without having to add a cast on each of those names. (ISO C++ forbids converting a string constant to 'CHAR*').
If you want it, I have a PR ready with this fix.