Click here to Skip to main content
11,924,487 members (61,115 online)
Rate this:
Please Sign up or sign in to vote.
See more: C++
Hi we know strcpy_s has been introduced as a secure version of strcpy.
It's signature is:
errno_t strcpy_s(
   char *strDestination,
   size_t numberOfElements,
   const char *strSource 
But I have a feeling it is still not secure. Although we specify length of destination buffer (e.g., numberOfElements) -- imagine if someone specifies false numberOfElements value, and sets it to 100 say, when the size of destination in reality, is 50? What happens in such a case?

What is your opinion? So I am thinking to evaluate code which contains
functions inside it and must provide some recommendation.
Posted 14-Nov-12 11:55am
Edited 14-Nov-12 11:56am
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

You can only prevent so much stupidity.... with that said, it can't stop you from writing bad code, it prevents you from overwriting a buffer which you've defined... so you should know the size (i.e. it's the size of the destination string or buffer, not the originating string). This function only prevents a large input string from overflowing a destination string.
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

As Schiller said: "Against stupidity the gods themselves contend in vain."

strcpy_s is not secure against invalid inputs. It's still worth using instead of the old strcpy, since it's more secure.

There's no absolute security that guards against all concievable invalid parameters, so it's not "secure". It's "more secure".
Rate this: bad
Please Sign up or sign in to vote.

Solution 4

As matter of fact, the standard C library (functionally equivalent) function (namely strncpy[^]) it is not 'advertised' as secure.
Orjan Westin 15-Nov-12 6:08am
No, strncpy isn't equivalent, as it doesn't stop at /0 like strcpy and strcpy_s does.

It's intended to solve a different problem, namely copying to fixed-length data fields.

strcpy_s is a standard C library function as of C11. It replaces the common compiler-vendor extension strcpy_r.
CPallini 15-Nov-12 7:52am
You are right on this (the padding).
In any case it doesn't matter the 'intended purpose' if you can effectively use it to prevent the buffer overflow.
Orjan Westin 15-Nov-12 8:14am
Using strncpy as a safe strcpy is very likely to lead to other buffer problems, since a null terminator is not given. If you were to do a strlen on the destination string later on, there's no telling what it might be, but you could easily take it at face value and assume that's the length of it. If you take this as a maximum length of that buffer and copy another string to it, you have your buffer overflow.
CPallini 15-Nov-12 8:24am
Well, you are right again. I stand corrected.
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

These are the versions with security enhancements. You tagged this C++. This function should not exist in C++ code, it is C, and is made redundant by string classes.
Albert Holguin 14-Nov-12 17:29pm
Unless you see C++ as a superset of C... in which case having C in C++ is not really a problem. Matter of opinion at that point...
Christian Graus 14-Nov-12 17:31pm
I disagree. C++ was built on C so people would adopt it. It's a bit like saying that because your high school years were built on your primary school years, it's OK to approach a complex problem with only primary school maths. The C part of C++ is utterly redundant today.
Albert Holguin 14-Nov-12 17:35pm
Like I said... it's a matter of opinion. I know a lot of people still like to use C-style code.
Christian Graus 14-Nov-12 17:37pm
Mostly because their teachers didn't know C++ but claimed they did, and taught C. Or they learned C first and never learned better
Albert Holguin 14-Nov-12 17:44pm
My internet access is super slow at work right now... but let's just agree to disagree. :)
Christian Graus 14-Nov-12 17:50pm
*grin* yes, it seems we're unlikely to agree on this :-)
Albert Holguin 14-Nov-12 17:35pm
You learned to add when you were in primary school... does that mean it's no longer applicable? ..not at all..
Christian Graus 14-Nov-12 17:38pm
Well, the analogy may seem imperfect, but the fact is there is no good reason, EVER, to worry if strcpy_s is secure on the basis that you refuse to use the far better and far safer string classes. Give me one time where using char * is BETTER, as opposed to the lazy way out for those who don't know how to use C++ properly ?
Albert Holguin 14-Nov-12 17:42pm
Passing strings between libraries and an executable... it's VERY commonly done.
Christian Graus 14-Nov-12 17:50pm
Sure, that's why string classes have a method that returns a char * if you need it for legacy stuff
Orjan Westin 15-Nov-12 5:03am
C++03 incorporates almost all of C99, and it's a stated aim of the C++ standard committee (ISO/IEC JTC1/SC22/WG21) to maintain C compatibility.

strcpy_s is a C11 addition, and as such hasn't been incorporated into C++11. In other words, it's C, at the moment, but likely to become C++ in the next revision to the standard.
Christian Graus 15-Nov-12 7:48am
Sure, I can see why they maintain C compatibility, it's powerful that C++ code can include any C code. Still no reason to use char * instead of a string class.
Orjan Westin 15-Nov-12 8:23am
Except when calling 3rd-party library and OS functions with C interfaces. Without an ABI for std::string and the rest of the standard library, C-style char* strings will be in common use in C++.
Christian Graus 15-Nov-12 9:05am
But std::string can return a char * for those moments.
Orjan Westin 15-Nov-12 9:24am
Yes, when you have a const input parameter. When it's a mixed in/out or an output parameter, you have to provide a buffer, and in some cases a pointer to a char* that the function creates a buffer for.

In most cases std::string and std::vector can be used for these occasions, but there are times, when calling a number of C functions in sequence, when it's most efficient to use C style code throughout that section.

That's not even considering all the C++ code that predates the standard library, and which is still maintained.

So while I agree that new code usually have no use for the C lib functions, most C++ programmers would benefit from learning them.
Christian Graus 15-Nov-12 9:25am
I don't disagree. But, they NEVER benefit from ONLY learning them, that is the core issue.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.151125.3 | Last Updated 15 Nov 2012
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100