An interesting trick: avoid dangling for strings

Hello everyone,

Yesterday I was writing a piece of code to interface with C, and I found an interesting thing I wanted to share. I would like feedback to know if it is correct as well, I am not 100% certain.

The context is: how can I make sure I only accept a string literal for a function to not endanger dangling?

Here it goes:


So I had this function:

void pthread_set_name_np(pthread_t thread, const char *name);

That I wanted to encapsulate to give my thread a name. The string for name is never copied, hence, it is easy you can make it dangle:

void setThreadName(const char * name, std::optional<std::reference_wrapper<std::thread>> thread = std::nullopt) {
  auto nativeHandle = thread.has_value() ? thread.value().get().native_handle() : pthread_self();
  pthread_setname_np(nativeHandle, name);
}

If name buffer provenance is passed as a temporary string and goes out of scope, then it would dangle:

...
{
   std::string threadName = "TheNameOfTheThread";
   setThreadName(threadName.data());
}

// string is destroyed here, .data() points to dangling memory area.

So the question is:

How can I enforce a string literal is passed and nothing else?

I came up with this:

struct LiteralString {
        char const* p;

        template<class T, std::size_t N>
        requires std::same_as<T, const char>
        consteval LiteralString(T (&s)[N]) : p(s) {}
};


void setThreadName(LiteralString name, std::optional<std::reference_wrapper<std::thread>> thread = std::nullopt) {
  auto nativeHandle = thread.has_value() ? thread.value().get().native_handle() : pthread_self();
  pthread_setname_np(nativeHandle, name.p);
}

std::string threadName("threadName");

setThreadName(threadName.data()); // FAILS, const char * not compatible.

// Works, does not dangle, since a string literal is static and an lvalue
setThreadName(LiteralString("threadName")); 

Any thoughts? Is this correct code? How would you make it more ergonomic, maybe with some conversion?












https://redd.it/1p6x4qr
@r_cpp