strcpy_s vs strcpy
in [C++]
|
Prev: composition and bad_alloc
Next: ANN: Library dependency graphs tool status update and questions
From: Thomas Richter on 2 Jul 2008 23:53 Greg Herlihy schrieb: > On Jul 2, 4:33 am, Trups <Samant.Tru...(a)gmail.com> wrote: >> I have changed my strcpy to strcpy_s for 2005 project. It's fairly >> big project and was using strycpy lot of places. > > It might helpful to provide a little background information here - > since many C++ programmers are probably not familiar with > "strcpy_s()", and the other routines described in the ISO C > Committee's Technical Report 2. The TR2 document (a draft of which can > be found on the ISO C Committee's web site): > > http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1225.pdf > > describes a "bounds-checking" interface to the Standard C Library. I wonder why there is a need for an additional interface if there are already functions that do that for you? Or to put this in different words, what's wrong with strncpy() that makes strcpy_s necessary? So long, Thomas -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 2 Jul 2008 23:55 Mathias Gaunard wrote: > Apart from the part it's perfectly useless Microsoft-specific > monstruosity and duplicates the standard strncpy, I do not think there > is any. You are entitled to your opinion, however it is no longer and entirely MS function and it does not in fact duplicate strncpy though there is a considerable overlap. -- Note that robinton.demon.co.uk addresses are no longer valid. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bart van Ingen Schenau on 3 Jul 2008 06:45 Thomas Richter wrote: > Greg Herlihy schrieb: >> On Jul 2, 4:33 am, Trups <Samant.Tru...(a)gmail.com> wrote: >>> I have changed my strcpy to strcpy_s for 2005 project. It's fairly >>> big project and was using strycpy lot of places. >> >> It might helpful to provide a little background information here - >> since many C++ programmers are probably not familiar with >> "strcpy_s()", and the other routines described in the ISO C >> Committee's Technical Report 2. The TR2 document (a draft of which >> can be found on the ISO C Committee's web site): >> >> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1225.pdf >> >> describes a "bounds-checking" interface to the Standard C Library. > > I wonder why there is a need for an additional interface if there are > already functions that do that for you? Or to put this in different > words, what's wrong with strncpy() that makes strcpy_s necessary? There is nothing wrong with strncpy, but both functions do a different job. One major difference is that strcpy_s guarantees that the destination buffer contains a string after the function returns. strncpy on the other hand does not make such a guarantee. If the source string is more than n characters long, the destination will *not* contain a string. On the other hand, I don't see any real advantage in the _s-functions. I don't expect that I will use them often if they become available for my platforms. > > So long, > Thomas > Bart v Ingen Schenau -- a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq c.l.c FAQ: http://c-faq.com/ c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/ [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Martin Bonner on 3 Jul 2008 06:45 On Jul 3, 3:53 pm, Thomas Richter <t...(a)math.tu-berlin.de> wrote: > Greg Herlihy schrieb: > > > On Jul 2, 4:33 am, Trups <Samant.Tru...(a)gmail.com> wrote: > >> I have changed my strcpy to strcpy_s for 2005 project. It's fairly > >> big project and was using strycpy lot of places. > > > It might helpful to provide a little background information here - > > since many C++ programmers are probably not familiar with > > "strcpy_s()", and the other routines described in the ISO C > > Committee's Technical Report 2. The TR2 document (a draft of which can > > be found on the ISO C Committee's web site): > > > http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1225.pdf > > > describes a "bounds-checking" interface to the Standard C Library. > > I wonder why there is a need for an additional interface if there are > already functions that do that for you? Or to put this in different > words, what's wrong with strncpy() that makes strcpy_s necessary? strncpy does /not/ nul terminate if the buffer is too short - that's the really killer problem. It also has performance issues with small strings to big buffers because it /must/ zero fill (but this is less of a problem). (strcpy_s /may/ fill - but it doesn't /have/ to). -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Greg Herlihy on 4 Jul 2008 10:27
On Jul 3, 7:53 am, Thomas Richter <t...(a)math.tu-berlin.de> wrote: > I wonder why there is a need for an additional interface if there are > already functions that do that for you? Or to put this in different > words, what's wrong with strncpy() that makes strcpy_s necessary? For one, strncpy() has no parameter specifying the size of the destination buffer - and therefore strncpy() has no way to verify that the destination buffer will not be overrun by the copied characters. For another, strcpy_s enforces a set of "runtime constraints": whereas calling strncpy() with a NULL pointer or with a negative number of characters to copy will result in undefined behavior, calling strncpy_s() with those arguments will cause a runtime constraint violation - but will not result in any undefined behavior. Lastly, (and more subtly) strcpy_s guarantees that the string in the destination buffer will be nul-terminated. Because, if the result is of the string copy operation is not a nul-terminated string, then even calling strlen() on it can result in undefined behavior. Greg -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |