strlcpy

strlcpy

Posted Jun 12, 2003 15:10 UTC (Thu) by Peter (guest, #1127)
In reply to: strlcpy by ncm
Parent article: strlcpy

Worse, each instance of strlcpy in a program indicates a potential bug in its own right.

That's like saying "each instance of malloc in a program indicates a potential memory leak in its own right." True, but uninteresting.

strlcpy truncates your string, sure - but it gives you enough information to trivially detect this, so you can either

1. use the truncated string,
2. return some sort of error condition, or
3. reallocate your buffer and try again.

I've seen many instances in code where a buffer is allocated to be plenty long enough for any sane input. In which case if the program truncates your input and thus behaves incorrectly, the user has only himself to blame, for giving "unreasonable" input. For example, if a web server returns a "404 not found" because you asked for a filename longer than (say) 1024 characters - I would consider that, not a bug, but just a "that case is not worth the trouble to support, and `404 Not Found' is a perfectly reasonable approximation for `You Seem To Be Trying To Overflow A Buffer, Get Lost'."

As far as security implications go: all user input should in general be considered untrusted and invalid until proven otherwise. The fact that it may or may not have been truncated is irrelevent.

Obviously there are other cases where it is appropriate to detect the truncation and deal with it some way (either with an explicit error condition, or a realloc). But it would seem counterproductive to deny the existence of cases where truncation really is a safe and correct option.

---

(Log in to post comments)