Thread: strcat_s problems

Originally Posted by Aisthesis

interesting the discussion on deprecation and IDEs.

to Salem: So, if the number is supposed to be the SIZE of the destination string buffer, and my destination string buffer is FullName[46], does that mean that I need to use 46 every time? like as first command

strcpy_s(FullName, 46, Last);

Yes, that or better yet, sizeof(FullName).

I also agree that some functions cannot simply be wrapped in macros. They can be a little more problematic, and perhaps should be avoided by newbies, but strcat_s and strcpy_s are very, very easy using macros:

Code:

#ifndef _MSC_VER
#define strcpy_s(dst, dst_length, src) strcpy(dst, src)
#endif

And one should also remember that these so called "secure" functions may not be secure (misleading name), but they DO protect against programmer mistakes, such as out-of-bounds writing which is helpful to any programmer to aid in debugging and especially to newbies who can very easily make such mistakes.

So when compiling in MSVC, we get added debugging functionality (good), and if we compile in another compiler, it will still compile due to the macro wrapper, so it essentially becomes ISO standard code (good). So no harm comes at all.
This is what I base my suggestion at.
I might or might not suggest the same for other "safe" functions. And I do agree that there's a lot of broken documentation and a poor word of saying they aren't recommended.

> Yes, that or better yet, sizeof(FullName).
Or not.
The OP was allocating memory, so sizeof isn't going to do what you want.

> but they DO protect against programmer mistakes,
But only if you're smart enough to RTFM and understand what it's telling you.
As the OP demonstrated in #6, if you LIE about the size of the buffer you're using, then you're no better off than you were before.

Except that you might get into a mind-set that so long as it doesn't actually crash, then your use of _s functions somehow makes it all nice and safe.

Originally Posted by cyberfish

But the problem is, if the programmer relies on the buffer size checking function, the code, when compiled by another compiler, won't be secure (since the dst_length parametre is macro'ed out).

So the portable way would be to make sure the buffer size is big enough manually BEFORE calling strcpy(_s). At that point... might as well just call the standard function.

As I pointed out, it's not necessarily more secure at all. If you want to call an assert/crash more secure, then sure. Otherwise it's merely a debugging tool and not a security measure (then it would simply fail and return an error).
So for your second argument that becomes invalid too - because the *_s functions is a tool to help you catch mistakes where you didn't make your buffer big enough.
You really should make the buffers big enough in the first place, the "secure" functions won't fix that, but it will tell you if you screwed up.

Originally Posted by Salem

> Yes, that or better yet, sizeof(FullName).
Or not.
The OP was allocating memory, so sizeof isn't going to do what you want.

True, when formulating that reply, I was looking at the...

FullName[46]

...bit.
So if using a local buffer, ie char FullName[46], then sizeof will be right. If dynamically allocated via new, then it is not correct.

> but they DO protect against programmer mistakes,
But only if you're smart enough to RTFM and understand what it's telling you.
As the OP demonstrated in #6, if you LIE about the size of the buffer you're using, then you're no better off than you were before.

Everything needs the knowledge to use it. Compiler warnings and errors and no different.
When you see a warning, you look it up and fix it. Normally anyway.
Though a newbie may not do this, so I do not see how it differs from that of compiler warning outputs.

Except that you might get into a mind-set that so long as it doesn't actually crash, then your use of _s functions somehow makes it all nice and safe.

Ah yes, pitfalls. There are always those, and I don't think this is an exception.
And I don't think we should consider something bad because of a few pitfalls.
As with everything, it helps to understand the function and what it does and what it does not do.

*shrugs*
What else can I say?