5 ms·

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-bett

by jabl 4y 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 4y 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 4y 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 4y 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 4y 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 4y ago
    There is a reason why hardware memory tagging is now trending across all new hardware platforms.
Bilgus_sugliB 4y 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 4y 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.)

by jabl 4y ago

quietbritishjim 4y 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 4y 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 4y 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 4y 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 4y ago
  There is a reason why hardware memory tagging is now trending across all new hardware platforms.

Bilgus_sugliB 4y 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 4y 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.)