Talk:Strcpy

Would someone like to take on the issue of NULL pointers passed in as destination or source strings ??

I find that src can be NULL on some platforms, and other will cause segfaults.

Corrections[edit]

I removed the sizeof(char) multiplication from the malloc lines because sizeof(char) is garanteed to always be 1 in the C language specification (this is not always true with wide characters, but they use wchar_t or some other type) --Michael Lynn 02:29, 2 November 2006 (UTC)[reply]

Bounds checking variants[edit]

I changed the name of this section from strncpy to bounds checking variants because this section talks about 3 variants, only one of which was strncpy...it also makes this article look match strcat better because they have a similar section. I also added a note that strncpy will zero out all the data in the output buffer up to the max length because this has some performance drawbacks (many large programs have replaced strncpy for this reason)...I also added in a cautionary note that strncpy does not null terminate strings if there is max len bytes or byte of input as this has stability concerns --Michael Lynn 01:45, 2 November 2006 (UTC)[reply]

strncpy[edit]

Search for strncpy shows the strcpy page. This is confusing. Once I worked out that I was not continually mistyping strncpy I looked for strncpy info on the strcpy page. There is very little info and the strcpy page does not show strncpy syntax. 82.33.206.46 12:47, 14 March 2007 (UTC)william[reply]

I suppose it could be merged with strcat creating a "strcpy and friends" article, perhaps even by merging strlcpy. It would avoid duplicate information about buffer overflows, segmentation faults, references to c-strings, etc. Sedulus 13:33, 13 April 2007 (UTC)[reply]

Half of this complaint could be solved by improving the information on strncpy in this article. NicM 21:48, 25 April 2007 (UTC).[reply]

I agree- strncpy is very different, because it automatically prevents buffer overflows, which cause more problems than viruses. The argument list for strncpy has an extra parameter, length, which is mentioned nowhere in this article. To fully document C, strncpy needs it's own place, even if on this page as a variant.

Merge strlcpy[edit]

Per above (strncpy), I think it's time to do this, given that strcpy_s is inline here and strlcpy is a separate article. The big question in my mind is what to call the resulting article. C string functions, maybe? --Steven Fisher 21:26, 25 April 2007 (UTC)[reply]

I oppose, strlcpy has enough material for an article of its own, there is no reason to merge them all into one big messy article. I say merge anything without sufficient material for its own article into a section in strcpy with redirect and leave everything else seperate with see also. NicM 21:44, 25 April 2007 (UTC).[reply]

Ie, leave it as it is now. If people are really being confused by multiple topics in one, perhaps a "This article also covers the related strncpy, see the table of contents to locate information on this term." header a la lowercase and friends would be a nice option. NicM 21:46, 25 April 2007 (UTC).[reply]

Then do we split strcpy_s out of this article? --Steven Fisher 16:36, 26 April 2007 (UTC)[reply]

Is there enough material available to make it its own article and someone willing to write it? NicM 08:01, 27 April 2007 (UTC).[reply]

I don't really think so, but I don't really think there's enough for strlcpy, either. Putting strcpy_s here and strlcpy in a separate article has the effect of seeming to promote strcpy_s to strcpy readers, which is undesirable. On the other hand, strcpy and its bounds-checking variants, and the issues related to picking one or the other, are all on-topic to strcpy. --Steven Fisher 06:22, 29 April 2007 (UTC)[reply]

There is no reason we can't mention strlcpy together with strcpy_s in this article, but I think the strlcpy article itself is fine as it is and don't see any need to merge it, particularly as that would bring a lot of strlcpy-specific material into strcpy. The promotional effect is very minor at worst, it could easily be argued the other way round, that giving strlcpy its own article is giving it more weight that strcpy_s. NicM 09:32, 29 April 2007 (UTC).[reply]

Not that I think they necessarily deserve equal weight. strlcpy/strlcat are probably the most widely known and widely used bounded variant, they were among the first to appear officially as part of an operating system and are now in several libcs as well as being copied into the source trees of lots of other projects, have generated some discussion both of their use and implementation, and have a USENIX paper covering their design. NicM 09:44, 29 April 2007 (UTC).[reply]

I've added a companion section on strlcpy to the existing strcpy_s section, together with {{main|strlcpy}}. NicM 10:06, 29 April 2007 (UTC).[reply]

strncpy(dest, NULL, 0)[edit]

Is strncpy() with a NULL source pointer but zero bytes to be copied from it "undefined behaviour" according to the C spec. -- Ralph Corderoy (talk) 10:38, 25 July 2011 (UTC)[reply]

It appears the answer is the same as memcpy(x, NULL, 0), however I can't find any answer for that. All sample code for strncpy I can find will work as they check the n before the look at what the pointer points at.Spitzak (talk) 19:21, 25 July 2011 (UTC)[reply]

Be it good or ill, that's not enough. I know of at least one incident where the GCC developers changed how a particular undefined behavior was handled for no other reason than to break existing code and scare the hell out of people. - Richfife (talk) 20:01, 25 July 2011 (UTC)[reply]

Pages for each function and WP:NOTMANUAL[edit]

Hello. You might find this discussion relevant. Thanks!1exec1 (talk) 09:07, 4 October 2011 (UTC)[reply]