6 ms·

There have been various attempts to improve on strcpy() etc. The current thinking is that strscpy() is the best general interface to this functionality. See the

There have been various attempts to improve on strcpy() etc. The current thinking is that strscpy() is the best general interface to this functionality. See the "improving ... strcpy" section at https://www.pixelbeat.org/programming/gcc/string_buffers.html https://www.pixelbeat.org/programming/gcc/string_buffers.htm...

TonyTrapp 3y ago
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 3y ago
  As mentioned in the article linked above https://saagarjha.com/blog/2020/04/12/designing-a-better-strcpy/ https://saagarjha.com/blog/2020/04/12/designing-a-better-str... , memccpy() comes relatively close and is slated to be part of C23.
  - quietbritishjim 3y ago
    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 3y ago
      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 3y ago
    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 3y ago
      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 3y ago
        There is a reason why hardware memory tagging is now trending across all new hardware platforms.
  - Bilgus_sugliB 3y ago
    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 3y ago
      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.)

TonyTrapp 3y ago

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 3y ago
As mentioned in the article linked above https://saagarjha.com/blog/2020/04/12/designing-a-better-strcpy/ https://saagarjha.com/blog/2020/04/12/designing-a-better-str... , memccpy() comes relatively close and is slated to be part of C23.
- quietbritishjim 3y ago
  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 3y ago
    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 3y ago
  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 3y ago
    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 3y ago
      There is a reason why hardware memory tagging is now trending across all new hardware platforms.
- Bilgus_sugliB 3y ago
  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 3y ago
    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.)