strcpy_s is it secure

Question

0.00/5 (No votes)

See more:

Hi we know strcpy_s has been introduced as a secure version of strcpy.
It's signature is:

C++

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

C++

strcpy

functions inside it and must provide some recommendation.

Posted 14-Nov-12 10:55am

WebMaster

Updated 14-Nov-12 10:56am

v2

Add a Solution

4 solutions

Add a Solution

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

Albert Holguin · Answer 1 · 2012-11-14T11:28:00

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.

Orjan Westin · Answer 2 · 2012-11-14T23:10:00

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".

CPallini · Answer 3 · 2012-11-14T23:58:00

Solution 4

As matter of fact, the standard C library (functionally equivalent) function (namely strncpy[^]) it is not 'advertised' as secure.

Posted 14-Nov-12 23:58pm

CPallini

Comments

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.

Christian Graus · Answer 4 · 2012-11-14T10:57:00

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.

Posted 14-Nov-12 10:57am

Christian Graus

Comments

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<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.

Christian Graus 15-Nov-12 9:25am

I don't disagree. But, they NEVER benefit from ONLY learning them, that is the core issue.

strcpy_s is it secure

4 solutions

Solution 2

Solution 3

Solution 4

Solution 1

Add your solution here

Preview 0

strcpy_s is it secure

4 solutions

Solution 2

Solution 3

Solution 4

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us