Talk:Strlcpy

Text and/or other creative content from this version of strlcpy was copied or moved into C string with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

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)[reply]

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)[reply]

("Aliased"?)

How much would two separate articles actually differ from each other, though? --Piet Delport 18:17, 11 April 2006 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

I think they are better apart. This article is substantial enough, isn't it? NicM 07:26, 2 November 2006 (UTC).[reply]

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)[reply]

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. —Preceding unsigned comment added by 62.189.88.194 (talk • contribs) 13:17, January 9, 2007

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)[reply]

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).[reply]

Performance issue with strncpy ?!

From the page, "For performance reasons, strlcpy does not fill any unused space in a destination string with zeros, unlike strncpy." strncpy is not supposed to fill any unused space with zeroes. I'd be very surprised to see a system do that. —Preceding unsigned comment added by 193.50.110.133 (talk • contribs) 13:00, December 1, 2008

There seem to be quite a few results when you search Google for "strncpy zeroes". For example, this one. Are you sure? Can you provide any sources? AlistairMcMillan (talk) 14:38, 1 December 2008 (UTC)[reply]

Looks like this might the source of the "performance reasons" sentence. We'd need some source to say that de Raadt and Miller are wrong. Or perhaps they are only talking about a particular implementation of strncpy? AlistairMcMillan (talk) 14:41, 1 December 2008 (UTC)[reply]

Oops, the SUS indeed says "If the array pointed to by s2 is a string that is shorter than n bytes, null bytes shall be appended to the copy in the array pointed to by s1, until n bytes in all are written.". How strange a behavior... Definitely good to know... —Preceding unsigned comment added by 193.50.110.133 (talk • contribs) 14:56, December 1, 2008

deletion

See Talk:C string#strlcpy. 1exec1 (talk) 12:19, 19 October 2011 (UTC)[reply]