So if someone is telling you not to trim the lead...I'll let you draw your own conclusion.

Negative lengths are not compatible with unsigned representation.

A system implementing invalid string values must choose a text encoding such as UTF-8 that supports the concept of an invalid character. Null termination is too flexible. As such is simple length prepending.

Let's take strstr, which finds a matching substring needle in a haystack string.

-returns a NULL string if the needle is not in the haystack. -returns pointer to first matching substring.

Extend strstr with VALIDITY

Understood behaviour if both are valid.

Say the haystack is INVALID...as the return value is NULL or a strict substring of haystack, should return INVALID. A poison haystack should poison dependent strings.

Say the haystack is valid but the needle is INVALID...should return NULL. A valid string never contains an INVALID string as a subsequence.

I would say let an INVALID string be length 0. Then accept that catting a valid and invalid string would result in a shorter length.

Which one do you think is safer?

I understand how one could shoot down implementations, but none has made a convincing argument about shooting down the idea.

memcpy and company are strictly for raw unencoded buffers.

We have the empty string: "\0"

We have the null string: NULL

There is no concept of an INVALID string, as float has NAN.

This would be the result of trying to copy a string to a buffer that is too small.

Or sprintf() into a small buffer.

Or a raw string parsed as UTF-8 and is invalid.

Correctness over efficiency.

  #include "Protocol.h"

  #include "comms/comms.h"

  namespace cc = comms_champion;

  namespace demo
  {

  namespace cc_plugin
  {

  Protocol::~Protocol() noexcept = default;

  const QString& Protocol::nameImpl() const
  {
      static const QString& Str("Demo");
      return Str;
  }

  }  // namespace cc_plugin

  }  // namespace demo

  // Put this in header to help user calculate allocation needs but hide size from user
  size_t LIBNAME_alloc_size(param1, param2, ...);

  // Put this in the header to hide the size from user code but allow inlined size calculations
  extern const size_t LIBNAME_ALLOC_X;

  // Put this in the header to make size known to user (for static const allocation)
  #define LIBNAME_ALLOC_Y ((size_t)42)

The following videos of my pig demonstrate this.

Video 2: Pig is first learning the task.

Video 3: Pig has slightly optimized the task.

Video 1: Pig has mastered the task.

https://www.dropbox.com/sh/37f48azh2bt4xk4/Wy3iHDMp1e?previe...