3 ms·

http://webcache.googleusercontent.com/search?q=cache:PptRk2k3FKIJ:https://symas.com/the-sad-state-of-c-strings/&num=1&hl=en&gl=ch&strip=1&vwsrc=0 http://webcach

http://webcache.googleusercontent.com/search?q=cache:PptRk2k3FKIJ:https://symas.com/the-sad-state-of-c-strings/&num=1&hl=en&gl=ch&strip=1&vwsrc=0 http://webcache.googleusercontent.com/search?q=cache:PptRk2k... This topic is a triviality of C programming. You run into performance (or usability) issues with standard strings - you roll out your own. It takes... what?... 20 minutes? OK, maybe an hour. Would it help to have an alternative standardized? Perhaps. Is it critical to have it? Hell, no.

derefr 11y ago
I presume the majority of the point of standardizing is in controlling what implementation third-party libraries use. It's not like libraries are grabbing opaque String* handles from some String.new-alike in libc, where all the strings in your final linked program could be replaced with a better implementation of the same ADT just by linking in a better String.new. The C standard says that "strings" are examinable buffers of bytes you can do arithmetic to and stream until NUL—and thus, every single library that uses C strings ends up baking in a bunch of pointer arithmetic and NUL-checks on buffers of bytes. It doesn't matter how optimized your own code's string implementation is if 99% of your time is spent in, for example, OpenSSL's string implementation.
draw_down 11y ago
In what other context anywhere in programming is it considered a good idea for everyone to hand-roll their own, separate, subtly-incompatible, surely-bug-ridden implementation of functionality that everyone needs? Gahhh.
- hyc_symas 11y ago
  Exactly. We can't kill strcpy/strcat, for backward compatibility reasons. But the standard ought to have a spec that is actually useful and not ridiculously sub-optimal. strlcpy() doesn't fit the bill either.
  - nkurz 11y ago
    I'm late to this discussion, but did you possibly miss stpcpy() and its variants? Or is something about them that doesn't meet your needs? STPCPY(3) Linux Programmer's Manual NAME stpcpy - copy a string returning a pointer to its end SYNOPSIS #include <string.h> char *stpcpy(char *dest, const char *src); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): stpcpy(): Since glibc 2.10: _XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L Before glibc 2.10: _GNU_SOURCE DESCRIPTION The stpcpy() function copies the string pointed to by src (including the terminating null byte ('\0')) to the array pointed to by dest. The strings may not overlap, and the destination string dest must be large enough to receive the copy. RETURN VALUE stpcpy() returns a pointer to the end of the string dest (that is, the address of the terminating null byte) rather than the beginning. CONFORMING TO This function was added to POSIX.1-2008. Before that, it was not part of the C or POSIX.1 standards, nor customary on UNIX systems, but was not a GNU invention either. Perhaps it came from MS-DOS. It is also present on the BSDs. BUGS This function may overrun the buffer dest. EXAMPLE For example, this program uses stpcpy() to concatenate foo and bar to produce foobar, which it then prints. #define _GNU_SOURCE #include <string.h> #include <stdio.h> int main(void) { char buffer[20]; char *to = buffer; to = stpcpy(to, "foo"); to = stpcpy(to, "bar"); printf("%s\n", buffer); } SEE ALSO memccpy(3), stpncpy(3), wcpcpy(3)
    - hyc_symas 11y ago
      Added to POSIX is good, but not sufficient. E.g., there is no reason for Windows to implement a function merely because it's in the POSIX spec. It needs to be in the C spec to actually be viable. stpncpy is equivalent to strncpy - it NUL-pads dest if the src is shorter than N. Frankly I have never found a use for this behavior. The desired behavior is to simply copy src without additional padding. That is what my proposed strecopy() does, and that's what would be required of a replacement for strlcpy().

derefr 11y ago

I presume the majority of the point of standardizing is in controlling what implementation third-party libraries use. It's not like libraries are grabbing opaque String* handles from some String.new-alike in libc, where all the strings in your final linked program could be replaced with a better implementation of the same ADT just by linking in a better String.new. The C standard says that "strings" are examinable buffers of bytes you can do arithmetic to and stream until NUL—and thus, every single library that uses C strings ends up baking in a bunch of pointer arithmetic and NUL-checks on buffers of bytes. It doesn't matter how optimized your own code's string implementation is if 99% of your time is spent in, for example, OpenSSL's string implementation.

draw_down 11y ago

In what other context anywhere in programming is it considered a good idea for everyone to hand-roll their own, separate, subtly-incompatible, surely-bug-ridden implementation of functionality that everyone needs? Gahhh.

hyc_symas 11y ago
Exactly. We can't kill strcpy/strcat, for backward compatibility reasons. But the standard ought to have a spec that is actually useful and not ridiculously sub-optimal. strlcpy() doesn't fit the bill either.
- nkurz 11y ago
  I'm late to this discussion, but did you possibly miss stpcpy() and its variants? Or is something about them that doesn't meet your needs? STPCPY(3) Linux Programmer's Manual NAME stpcpy - copy a string returning a pointer to its end SYNOPSIS #include <string.h> char *stpcpy(char *dest, const char *src); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): stpcpy(): Since glibc 2.10: _XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L Before glibc 2.10: _GNU_SOURCE DESCRIPTION The stpcpy() function copies the string pointed to by src (including the terminating null byte ('\0')) to the array pointed to by dest. The strings may not overlap, and the destination string dest must be large enough to receive the copy. RETURN VALUE stpcpy() returns a pointer to the end of the string dest (that is, the address of the terminating null byte) rather than the beginning. CONFORMING TO This function was added to POSIX.1-2008. Before that, it was not part of the C or POSIX.1 standards, nor customary on UNIX systems, but was not a GNU invention either. Perhaps it came from MS-DOS. It is also present on the BSDs. BUGS This function may overrun the buffer dest. EXAMPLE For example, this program uses stpcpy() to concatenate foo and bar to produce foobar, which it then prints. #define _GNU_SOURCE #include <string.h> #include <stdio.h> int main(void) { char buffer[20]; char *to = buffer; to = stpcpy(to, "foo"); to = stpcpy(to, "bar"); printf("%s\n", buffer); } SEE ALSO memccpy(3), stpncpy(3), wcpcpy(3)
  - hyc_symas 11y ago
    Added to POSIX is good, but not sufficient. E.g., there is no reason for Windows to implement a function merely because it's in the POSIX spec. It needs to be in the C spec to actually be viable. stpncpy is equivalent to strncpy - it NUL-pads dest if the src is shorter than N. Frankly I have never found a use for this behavior. The desired behavior is to simply copy src without additional padding. That is what my proposed strecopy() does, and that's what would be required of a replacement for strlcpy().