Click here to Skip to main content
Rate this: bad
good
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
strcpy 
functions inside it and must provide some recommendation.
Posted 14-Nov-12 10:55am
Edited 14-Nov-12 10:56am
v2
Rate this: bad
good
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.
  Permalink  
Rate this: bad
good
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".
  Permalink  
Rate this: bad
good
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.
  Permalink  
Comments
Orjan Westin at 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 at 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 at 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 at 15-Nov-12 8:24am
   
Well, you are right again. I stand corrected.
Rate this: bad
good
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.
  Permalink  
Comments
Albert Holguin at 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 at 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 at 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 at 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 at 14-Nov-12 17:44pm
   
My internet access is super slow at work right now... but let's just agree to disagree. :)
Christian Graus at 14-Nov-12 17:50pm
   
*grin* yes, it seems we're unlikely to agree on this :-)
Albert Holguin at 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 at 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 at 14-Nov-12 17:42pm
   
Passing strings between libraries and an executable... it's VERY commonly done.
Christian Graus at 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 at 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 at 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 at 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 at 15-Nov-12 9:05am
   
But std::string can return a char * for those moments.
Orjan Westin at 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<char> 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.</char>
Christian Graus at 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
0 Dnyaneshwar@Pune 994
1 Sergey Alexandrovich Kryukov 826
2 OriginalGriff 448
3 Tadit Dash 390
4 sanket saxena 323
0 Sergey Alexandrovich Kryukov 11,800
1 OriginalGriff 7,225
2 Peter Leow 5,009
3 Abhinav S 3,893
4 Maciej Los 3,575


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