Post by Nils O. SelåsdalIf you're reading input, you know how much input you did read, and how
how much you have read. I don't see why strlcpy helps in that regard.
But if you tokenize your input and don't care about the length of the
tokens, it often doesn't really make sense passing around the size of
the strings handled. I agree that you know the lengths most of the time,
but if buffer handling is the only reason passing these values around
and keeping them up-to-date, it is often easier to discard them and
calculate them if needed.
Post by Nils O. SelåsdalI also don't like randomly chopping off strings, which is what strlcpy
will do for you. It's better than the alternative of overflowing buffers
but imo both cases show you're sloppy in what you accept and validate
for your input.
----------
$ uname -a
SunOS anduril 5.10 Generic_118833-03 sun4u sparc SUNW,Sun-Blade-1000
$ man strlcpy
The strlcpy() function copies at most dstsize-1 characters
(dstsize being the size of the string buffer dst) from src
to dst, truncating src if necessary. The result is always
null-terminated. The function returns strlen(src). Buffer
overflow can be checked as follows:
if (strlcpy(dst, src, dstsize) >= dstsize)
return -1;
--------
So strlcpy returns the size of the input string and it gives you the
opportunity to resize the buffer if needed. So no data will be lost, and
here is nothing sloppy...
E.g.:
char *buffer; /* your buffer */
size_t bufsize; /* current size of the buffer */
while (strlcpy(buffer,src,bufsize) >= bufsize) {
buffer = realloc(buffer, bufsize += getpagesize());
assert(buffer);
}
This way of implementation is especially useful, if you can guess a
buffersize that is big enough for 99% of all cases. The missing cases
then can easily be handled like shown above. And don't forget that you
will need a struct or pointers to return a token from a function that
consists of char * and size_t. Using only char * can make things easier.
But this is probably also a matter of style.
Cheers,
Tom