Talk:Strlcpy
From Wikipedia, the free encyclopedia
Contents |
[edit] Article name
Since strlcpy and strlcat are usually very closely associated, maybe the article should be renamed to "strlcpy and strlcat", and discuss both? --Piet Delport 17:05, 11 April 2006 (UTC)
- My vote would be for separate pages. Aside from anything else "x and y" article titles are almost guaranteed to be aliased wherever they are used. AlistairMcMillan 17:12, 11 April 2006 (UTC)
-
- ("Aliased"?)
- How much would two separate articles actually differ from each other, though? --Piet Delport 18:17, 11 April 2006 (UTC)
-
-
- Sorry Wikipedia:Piped link, don't know where I got aliased from. So what is wrong with the current situation where strlcat redirects to strlcpy, which explains how strlcpy works and says strlcat works in the same way. What else would a page called strlcpy and strlcat" say? AlistairMcMillan 18:58, 11 April 2006 (UTC)
-
-
-
-
- Well, i had in mind something like the setjmp/longjmp article. In other words, not a major change, just something that treats the two more evenly, instead of hiding strlcat near the end. --Piet Delport 19:37, 11 April 2006 (UTC)
-
-
it might be a better fit to merge these with strcpy, they already have a section on bounds checking variants, and there is no article on strncat...perhaps making one large article with all the strcpy variants (because these area all just variants of strpy) that redirect on the various names --Michael Lynn 02:23, 2 November 2006 (UTC)
- I think they are better apart. This article is substantial enough, isn't it? NicM 07:26, 2 November 2006 (UTC).
[edit] Linus' criticism
I don't see how Linus pointing out that a particular chunk of code that uses strlcpy in a stupid way that doesn't solve the security problem is actually a criticism of strlcpy itself, so I'm removing the link. -- Steven Fisher 23:49, 14 August 2006 (UTC)
[edit] Harmful mempcpy() usage
The mempcpy() example is prone to reading outside of legal memory. Certainly if the source buffer is larger than the destination buffer (which is necessary to cause overflow) then it fixes the problem, but in the other case it only introduces a new one. Very bad form. —The preceding unsigned comment was added by 62.189.88.194 (talk • contribs) 13:17, January 9, 2007 (UTC)
[edit] Null termination
From the page: "strlcpy requires that the source string be properly null-terminated. When this condition is violated, strlcpy can leak information after the original source string into the destination buffer."
Surely this applies to strcpy and strncpy as well? They determine the size/end of the input string by detecting the null terminator. "When this condition is violated" would mean there is no null terminator, so the input isn't even a valid C string. What else can the function do but read into memory until the first null? 194.72.134.226 11:11, 12 February 2007 (UTC)
- Yeah, I think you are right. In practice, both of them will just copy up to len if src isn't null-terminated (although it is not clear if strlcpy guarantees that behaviour). The only difference is if src is null-terminated and len > strlen(src), strncpy will pad with nulls but strlcpy won't. That isn't an information leak though. NicM 14:30, 12 February 2007 (UTC).
