Remove deprecated score::StringLiteral by crimson11 · Pull Request #745 · eclipse-score/communication

crimson11 · 2026-07-22T16:30:38Z

Fixed wrong/outdated structural diagrams.

Removed usage of deprecated score::StringLiteral in Runtime.
Replaced with const safecpp::zstring_view on implementation
level. Public/user facing APIs using StringLiteral or char*
have been marked deprecated and overloads taking
safecpp::zstring_view have been introduced.

limdor

const char * has multiple problems and I do not think this should be the substitute for StringLiteral.

An std::string can be converted implicitly from const char * ending with dynamic memory allocation
const char* has the problem that it could be a pointer to characters or a pointer to an array of bytes. char meaning is way too overloaded in the standard
The fact that it is a pointer, it can end up in all the issues with pointer decay
It has no notion of being null terminated or not

Because of that, my proposal would be to go for better alternatives.

For main arguments, go with a container of null terminated string views. We can use https://github.com/eclipse-score/baselibs/tree/main/score/language/safecpp/string_view and https://github.com/eclipse-score/baselibs/blob/main/score/string_manipulation/arguments/arguments.h for that.
For global constant string literals with internal linkage, we can use zstring_view https://github.com/eclipse-score/baselibs/tree/main/score/language/safecpp/string_view
For the rest, I would propose to take a look one by one, depending if they are owning or not, and depending if they are null terminated or not.

Additional note: I saw that in several places you removed the usage of StringLiteral, but the dependency to the target and the include is still there. If we remove StringLiteral we should remove it completly and also remove the include files. Of course it can happen that we break some code if someone relies on the transitive dependency but imho this is a price the users need to pay if they did not have proper includes.

limdor · 2026-07-23T05:31:02Z

 constexpr auto kDeprecatedConfigurationPathCommandLineKey = std::string_view{"-service_instance_manifest"};
 constexpr auto kConfigurationPathCommandLineKey = std::string_view{"--service_instance_manifest"};

+void VerifyNullTermination(const std::int32_t argc, const char* argv[])


This is something that you cannot do. The problem of this is that if it is null terminated, you will find it, but if it is not null terminated, you hit undefined behavior.
In the second case, it could even be that you hit some null character in memory that it is totally unrelated.

LittleHuba

Please use C++ infrastructure. E.g. zstring_view or Arguments helper in baselibs.

crimson11 · 2026-07-23T07:00:57Z

OK. I guess, I will close this PR then. The thing is: All the usage of const char* stems from the main() entry-point! I.e. there you get const char*, which are guaranteed to be NULL-terminated.
I don't know, how to fix the "issue" then! We expect the user to hand over the char* he gets from the OS in main(). If you now want me to change the signature from our PUBLIC API, where the user currently hands over these char* from main() ... I can't do it.

@limdor , @LittleHuba : Maybe I'm wrong, but to me it seems, that all your input means/can only solved via changng the PUBLIC interface. I.e. require the user NOT to hand over the char* he gets from OS (cmd-line-args) .... if he then also needs to transform these char* to somethings else what is discussed here ... this might also mean eventually heap-allocation ...?

limdor · 2026-07-23T08:19:48Z

Yes, it means breaking public API. But the first step would be to provide a second overload that allows the user to use a container of zstring_view and deprecate the API that uses const char *.
And yes, depending how we do it, it might require allocation at startup for the container, but it can also be an allocation aware type.

limdor

For the moment I reviewed all changes in the design folder. I think it would be better to move them in a separate PR becasue how I see them is that none of them is related to an API change, it is just because the puml was wrong.

Then for the API additions, I did not review yet. But I assume we will have to update some puml files.

limdor · 2026-07-27T10:36:48Z

  - Runtime(std::pair<Configuration&&, std::optional<tracing::TracingFilterConfig>&&> configs)
  {static} + Initialize() : void
-  {static} + Initialize(const score::cpp::span<const score::StringLiteral> arguments) : void
+  {static} + Initialize(const score::cpp::span<const char*> arguments) : void


Why this change? This seems to already be wrong in the main branch.
Can you fix this in advance in a separate PR? It should only be one Initialize method

communication/score/mw/com/impl/runtime.h

Line 77 in e8abf72

static void Initialize(const runtime::RuntimeConfiguration& runtime_configuration);

limdor · 2026-07-27T10:37:13Z

  __
  {static} + Initialize() : void
-  {static} + Initialize(arguments : score::cpp::span<const score::StringLiteral>) : void
+  {static} + Initialize(arguments : score::cpp::span<const char*>) : void


Same as in https://github.com/eclipse-score/communication/pull/745/changes#r3656356347

limdor · 2026-07-27T10:38:38Z

-  {static} +Initialize() : void
-  {static} +Initialize(int argc, score::StringLiteral argv) : void
-  {static} +Initialize(std::string const&) : void
+  {static} +Initialize(runtime::RuntimeConfiguration&) : void


Can we move this changes to a separate PR together with https://github.com/eclipse-score/communication/pull/745/changes#r3656356347? That is not really a change in the API, it is just fixing the puml that was wrong.

limdor · 2026-07-27T10:39:01Z

    -binding_runtimes_ : std::unordered_map<BindingType, std::unique_ptr<IBindingRuntime>>
    +{static} Initialize() : void
-    +{static} Initialize(int argc, score::StringLiteral argv) : void
+    +{static} Initialize(int argc, const char* argv) : void


Same as https://github.com/eclipse-score/communication/pull/745/changes#r3656356347

limdor · 2026-07-27T10:47:59Z


 class "<< Stereotype >>\nglobal function" as GlobalFunction {
-  +MakeError(code : ComErrc, message : score::StringLiteral) : score::result::Error
+  +MakeError(code : ComErrc, message : const char*) : score::result::Error


Suggested change

+MakeError(code : ComErrc, message : const char*) : score::result::Error

+MakeError(code : ComErrc, message : const std::string_view) : score::result::Error

I believe this should be std::string_view. This is what we have in the implementation

communication/score/mw/com/impl/com_error.h

Line 224 in e8abf72

score::result::Error MakeError(const ComErrc code, const std::string_view message = "");

Because this is just fixing the puml, it would be good if we can move it out of this PR, because this is not an API change but fixing a mismatch in the puml.

Another thing about this but it was already there before your change, it seems that this says in the puml that it is a global function but it does not seem to mention the namespace. Not sure how you reflect that in puml, I'm not very familiar with it yet.

limdor · 2026-07-27T10:48:15Z


 class "<< Stereotype >>\nglobal function" as GlobalFunction {
-  +MakeError(code : ComErrc, message : score::StringLiteral) : score::result::Error
+  +MakeError(code : ComErrc, message : std::string_view) : score::result::Error


Same as https://github.com/eclipse-score/communication/pull/745/changes#r3656421146

Updated structural and binding model diagrams to reflect current code correctly.

Removed usage of deprecated score::StringLiteral in Runtime. Replaced with const safecpp::zstring_view on implementation level. Public/user facing APIs using StringLiteral or char* have been marked deprecated and overloads taking safecpp::zstring_view have been introduced. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

crimson11 requested review from LittleHuba, bemerybmw, castler, hoe-jo and limdor as code owners July 22, 2026 16:30

github-project-automation Bot added this to COM - Communication FT Jul 22, 2026

github-project-automation Bot moved this to Backlog in COM - Communication FT Jul 22, 2026

crimson11 force-pushed the mf_fix_use_string_literal_deprecated branch from d50e760 to 263c6ca Compare July 22, 2026 21:19

limdor requested changes Jul 23, 2026

View reviewed changes

limdor reviewed Jul 23, 2026

View reviewed changes

LittleHuba reviewed Jul 23, 2026

View reviewed changes

crimson11 marked this pull request as draft July 23, 2026 06:53

crimson11 force-pushed the mf_fix_use_string_literal_deprecated branch from 263c6ca to 9476fed Compare July 24, 2026 14:50

crimson11 marked this pull request as ready for review July 24, 2026 14:51

crimson11 force-pushed the mf_fix_use_string_literal_deprecated branch 4 times, most recently from ee86368 to 0758124 Compare July 27, 2026 09:44

limdor reviewed Jul 27, 2026

View reviewed changes

crimson11 and others added 2 commits July 27, 2026 14:22

Update design diagrams

255d01a

Updated structural and binding model diagrams to reflect current code correctly.

crimson11 force-pushed the mf_fix_use_string_literal_deprecated branch from 0758124 to 9667138 Compare July 27, 2026 12:22

crimson11 requested review from LittleHuba and limdor July 27, 2026 16:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Remove deprecated score::StringLiteral - #745

Remove deprecated score::StringLiteral#745
crimson11 wants to merge 2 commits into
mainfrom
mf_fix_use_string_literal_deprecated

crimson11 commented Jul 22, 2026 •

edited

Loading

Uh oh!

limdor left a comment

Uh oh!

limdor Jul 23, 2026

Uh oh!

LittleHuba left a comment

Uh oh!

crimson11 commented Jul 23, 2026 •

edited

Loading

Uh oh!

limdor commented Jul 23, 2026

Uh oh!

limdor left a comment

Uh oh!

limdor Jul 27, 2026

Uh oh!

limdor Jul 27, 2026

Uh oh!

limdor Jul 27, 2026

Uh oh!

limdor Jul 27, 2026

Uh oh!

limdor Jul 27, 2026

Uh oh!

limdor Jul 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	+MakeError(code : ComErrc, message : const char*) : score::result::Error
	+MakeError(code : ComErrc, message : const std::string_view) : score::result::Error

Uh oh!

Conversation

crimson11 commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

limdor left a comment

Choose a reason for hiding this comment

Uh oh!

limdor Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

LittleHuba left a comment

Choose a reason for hiding this comment

Uh oh!

crimson11 commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

limdor commented Jul 23, 2026

Uh oh!

limdor left a comment

Choose a reason for hiding this comment

Uh oh!

limdor Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

limdor Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

limdor Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

limdor Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

limdor Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

limdor Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

crimson11 commented Jul 22, 2026 •

edited

Loading

crimson11 commented Jul 23, 2026 •

edited

Loading