Add null_safe_string_view(const char*, std::size_t)

[alt-graph]

There are use cases for constructing a string_view with a specified size in a way that is protected against null pointers. This is notably different from the existing safe_string_view(const char*, std::size_t) which terminates the string at a null byte.

[Copilot]

Pull request overview

This PR adds a new overload of null_safe_string_view that accepts a length parameter, enabling construction of string_views with a specified size while protecting against null pointers. Unlike safe_string_view, which terminates at null bytes, this new function preserves embedded null bytes within the specified length.

Key Changes

• Added null_safe_string_view(const char*, std::size_t) overload that returns an empty string_view for null pointers and constructs a string_view with the specified length otherwise
• Comprehensive test coverage for the new function including null pointers, zero lengths, and embedded null bytes
• Updated changelog to document the new function

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
include/gul17/string_util.h	Added function declaration and documentation for the new overload; modified parameter documentation for existing overload
src/string_util.cc	Implemented the new null_safe_string_view(const char*, std::size_t) function
tests/test_string_util.cc	Added comprehensive test cases covering null pointers, zero/non-zero lengths, and embedded null bytes
data/doxygen.h	Added changelog entry for the new function in the UNRELEASED section

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Finii]

Ugg, this 'Pull Request Overview' really puts me off. I prefer a human generated explanation/overview, and this is just babble. If you absolutely need an LLM "bug finder", maybe we/you can at least re remove the blah as that increases the mental load any PR anyhow has.

To the topic...

a) A wonder if we can not somehow unify save_string_view() with the new functionality presented here with null_safe_string_view(). I will add something in the bottom.

For me, having 4 functions for "the same" is too much. Even 3 is too much and I must have overlooked it.

b) I imagine that sometimes you want to do something like this (feature idea):

    auto& setting_a = obj.settings.a;
    std::cout << null_save_string_view(setting_a.charptr, setting_a.length, "Option A unset");

---

The current documentation is already wrong:

Doxygen docu has copy&paste error?

Hmm, I wanted to compare the existing *safe_string*() functions. But that seems hard. It is too much cuddle muddle for me.

This is notably different from the existing safe_string_view(const char*, std::size_t) which terminates the string at a null byte.

And that null-byte give the null_ in null_save_string_view()? I find that not really plausible/catchy. Especially as it also 'could' mean nullptr 😬 .

Hmm, still trying to come up with a feature table

	creates string_view	can handle nullptr	preserves '/0'
safe_string()	➖	👍	👎
safe_string_view()	➕	👍	👎
null_safe_string()	➖	👍	👍
null_safe_string_view()	➕	👍	👍

So this looks like a reasonable extension/completion. But I believe we should have only 2 functions and not 4, and that the 'preserves '/0' should be handled differently (e.g. as nttp or optional parameter).

Hmm. The existing 3 functions are ... functions. Being in this library it means they can not be optimized away, I assume? Maybe they should be templates instead. That is what I believed they were.

Hmm:

• 050d97b Rename the new functions to null_safe_*()

Uggg:

• Add single-argument overloads safe_string(const char*) and safe_string_view(const char*) #29

It seems the whole feature and naming is more complicated than one would expect.
I think we should discuss this a bit more rigorously.
Obviously my table is not sufficient. A good tabe would also help users choose the right of the multiple functions in this family.

Maybe I'm wrong with this, but for me this feels like a thicket.

Edit: I guess by b) is too much (at least right now)

[alt-graph]

Ugg, this 'Pull Request Overview' really puts me off. I prefer a human generated explanation/overview, and this is just babble. If you absolutely need an LLM "bug finder", maybe we/you can at least re remove the blah as that increases the mental load any PR anyhow has.

To the topic...

a) A wonder if we can not somehow unify save_string_view() with the new functionality presented here with null_safe_string_view(). I will add something in the bottom.

For me, having 4 functions for "the same" is too much. Even 3 is too much and I must have overlooked it.

b) I imagine that sometimes you want to do something like this (feature idea):

    auto& setting_a = obj.settings.a;
    std::cout << null_save_string_view(setting_a.charptr, setting_a.length, "Option A unset");

The current documentation is already wrong:

Doxygen docu has copy&paste error?

Hmm, I wanted to compare the existing *safe_string*() functions. But that seems hard. It is too much cuddle muddle for me.

This is notably different from the existing safe_string_view(const char*, std::size_t) which terminates the string at a null byte.

And that null-byte give the null_ in null_save_string_view()? I find that not really plausible/catchy. Especially as it also 'could' mean nullptr 😬 .

Hmm, still trying to come up with a feature table
creates string_view can handle nullptr preserves '/0'
safe_string() ➖ 👍 👎
safe_string_view() ➕ 👍 👎
null_safe_string() ➖ 👍 👍
null_safe_string_view() ➕ 👍 👍

So this looks like a reasonable extension/completion. But I believe we should have only 2 functions and not 4, and that the 'preserves '/0' should be handled differently (e.g. as nttp or optional parameter).

Hmm. The existing 3 functions are ... functions. Being in this library it means they can not be optimized away, I assume? Maybe they should be templates instead. That is what I believed they were.

Hmm:

* [050d97b](https://github.com/gul-cpp/gul17/commit/050d97ba41be971807c2100737e133f540688e33) `Rename the new functions to null_safe_*()`

Uggg:

* [Add single-argument overloads safe_string(const char*) and safe_string_view(const char*) #29](https://github.com/gul-cpp/gul17/pull/29)

It seems the whole feature and naming is more complicated than one would expect. I think we should discuss this a bit more rigorously. Obviously my table is not sufficient. A good tabe would also help users choose the right of the multiple functions in this family.

Maybe I'm wrong with this, but for me this feels like a thicket.

Edit: I guess by b) is too much (at least right now)

I know that naming is complicated, but... let me just point out that the functions that are now called null_safe_string*() were originally proposed under the name safe_string*(), and a certain @Finii argued that they should have a different name. :)

Also, why is "the current documentation [...] already wrong"? I do not see that. The "null_safe_" functions only protect against null pointers, the "safe_" functions also terminate the string early at a null byte. In that regard, the new safe_string_view() overload is just the one missing extension.

We can discuss if we should inline these functions, but IMO that should be a different MR because we would also touch the existing functions.

[Finii]

I know that naming is complicated, but... let me just point out that the functions that are now called null_safe_string*() were originally proposed under the name safe_string*(), and a certain @Finii argued that they should have a different name. :)

I also mentioned that?

Also, why is "the current documentation [...] already wrong"? I do not see that.

The examples?

The "null_safe_" functions only protect against null pointers, the "safe_" functions also terminate the string early at a null byte. In that regard, the new safe_string_view() overload is just the one missing extension.

I just suggested putting this kind of explanation into the docs. What save_ and null_ means, such that one can more easily 'assemble' the function name to search for ;)

---

I guess the change is ok, but I would like to see the documentation fixed (Soeren would fix them in an additional PR, but I would fix them en passant). And maybe an expansion in the documentation similar to what you gave above.

[alt-graph]

I have fixed the Doxygen examples for two of the functions and tried to make the "first-line" description of each function as explicit as possible. Have another look – it really is an unpleasant thicket of functions now.

[alt-graph]

Force-pushed with a whitespace change.

[Finii]

Have another look – it really is an unpleasant thicket of functions now.

Maybe we should try a more organized approach and clean this up. Next year. If time permits 🤣