[TonyTrapp]

The sad part is really that there are several implementation of safe(r) string manipulation functions, they all do mostly the same thing, but have different names and parameter orders, preventing interoperability between major compilers. They really need to get their shit together and finally agree on a single variant to be standardized.

[jabl]

As mentioned in the article linked above https://saagarjha.com/blog/2020/04/12/designing-a-better-str... , memccpy() comes relatively close and is slated to be part of C23.

[Bilgus_sugliB]

The code in that blog article has a bug in it that I reported to the author like 6 months ago and hasn't fixed

it should be

  char *strxcpy(char *restrict dst, const char *restrict src, size_t len)
  {
    char *end = memccpy(dst, src, '\0', len);
    if (!end && len > 0) { dst[len - 1] = '\0';}
    return end;
  }

Not the end of the world but just another subtly bugged implementation..

This illustrates the issue..

Notice in the code below how it wipes out the dest string at char 0 when we supply buf[1]

if we didn't supply buf[1] the zero gets written at buf[size_t_max]

  #include <stdio.h>
  #include "string.h"

  char *strxcpy(char *restrict dst, const char *restrict src, size_t len) {
   char *end = memccpy(dst, src, '\0', len);
   if (!end) { dst[len - 1] = '\0';}
   return end;
   }

  int main()
  {
      char buf[3] = "??";
      printf("Hello World%s", buf);
      strxcpy(&buf[1], "test", 0);
      printf("Hello World%s", buf);

      return 0;
  }

[quietbritishjim]

Even without this, I don't think the claim that "memccpy() comes relatively close" to safe string manipulation can be taken seriously if it doesn't even null terminate the destination. That's a pretty core requirement.

(I mean, of course it doesn't null terminate given its intended usage, but that's what it would need for that claim.)

[quietbritishjim]

Goodness me, that is a terrible name. Lower case o and c are very hard to distinguish in the middle of a word, so that looks like memcopy (yes I know the actual existing function is memcpy but memmove is more common in application-ish code, and it includes the middle "o", so I still read memccpy wrong).

What next? merncopy?

[jabl]

Admittedly the name is poor, but memccpy has been in POSIX since forever (the opengroup.org manual mentions it's from "Issue 1" which I believe refers to the X/Open Issue 1 from 1985), so I guess the C committee thought that an existing poor name was better than coming up with a new one.

[pjmlp]

Nothing that requires separate pointer and length will be safe, no matter how many times they keep going at it, unless it is backed by hardware memory tagging.

[jabl]

That is undoubtedly true, but while we're waiting for the widespread acceptance of a C string library that defines a separate string type, or for the world to be rewritten in Rust or other safer languages, it's still possible to make incremental progress.

[pjmlp]

There is a reason why hardware memory tagging is now trending across all new hardware platforms.