Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The thing that annoys me the most about strlcpy is that it is supposed to be safer, but what happens in the case where the source string is not properly NULL terminated? You might think that it will stop at the character limit you specified, but that's not what it does. It just blows on past the end of the buffer looking for a \0 until it either finds one or causes a segmentation violation.

IMHO I would like it much more if the return values were:

  0: string copied
  1: string partially copied but truncated
  -1: Error, errno set.  This can occur when src or dst are NULL.


Linux's strscpy addresses these issues.


Which is great if you're a kernel developer, a bit of a moot point for application developers.


> what happens in the case where the source string is not properly NULL terminated

That’s not a string.


None of strlcpy, strncpy, and strcpy will know that you have not provided a string. They will assume the source pointer is a string and as such, will read (and write, in the case of strcpy) bytes until they find that NUL.

This is the upside of strlcpy. Whatever is in your output buffer is guaranteed to be a NUL terminated and have your desired length. strncpy does not make that guarantee. strcpy will give you something with a NUL terminator but it could be well past the end of the output buffer. Hello, CVE.

The more I write here, the more I realize how silly it would be to write anything dealing with human-readable text in C in 2023. I had been working on a C webserver a while back but I think I'm going to purge that from my local git server and start over with something else.


Passing something that is not a string to strcpy or strlcpy is undefined behavior. They operate on strings, which are null-terminated by definition. On the flip side, strncpy operates on character arrays, which do not have to be null-terminated. (This is also why the output buffer is not always null-terminated: it's not meant to represent a string, despite the highly confusing str- prefix.)


Look at the declarations:

  char *strcpy(char *dest, const char *src);
  char *strncpy(char *dest, const char *src, size_t n);
  size_t strlcpy(char *dest, const char *src, size_t size);
From that, how do you know that strncpy expects and produces a character array, strcpy expects and produces a string, and strlcpy takes either a character array or string and produces a string?

Your descriptions of the string/character copy functions are factual and accurate. But correct use depends on programmer understanding. You do not get any runtime guarantee. And IME, when you are under a deadline, 13 function calls and 3 message queues deep in some ancient codebase, while trying to get a non-trivial feature working, the distinction between a character array and a string is easily forgotten.

Anyways, my assertions are:

1) Using C for strings is a poor choice 2) If your compiler vendor or cranky boss forces use of C, use strlcpy to handle string copying.


I don't disagree, although I would suggest using something other than strlcpy because it also may not do what you want.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: