From: Larry Lindstrom on
Sebastian G. wrote:
> Nathan Mates wrote:
>
>> I have to say that I think it's gotten a fair bit better. I
>> actually appreciate MS's secure string handling functions, e.g.
>> strcpy_s vs strcpy.
>
>
> The will be included in the next version of the ISO C standard, so it's
> pretty safe to start using them now. Even though you example is bogus,
> since strncpy() is a already existing portable and secure standard
> solution.
>
>> (Yes, some people will say you should use std::string or such for
>> everything; I find that to be a lot more work and generally
>> counterintuitive to me.)
>
>
> A much simpler argument that std::string doesn't make any sense for pure C.

Thanks again Sebastian and Nathan and Peter:

It's working now. I threw a bunch of solutions at the issue, so I'm
now not certain which one broke the obstruction, but it's working.
I'm now running vcredist_x86.exe on each installation. I'll know if
this is the fix that worked when I try to install on another PC.

Nathan, I was referring to the reputation all of the Windows,
including Vista, have among people who deal with attacks on
computer systems. Perhaps these secure string operations have a
positive impact on that problem, I've never understood how a stack
overflow can open up access to a computer.

Among this community, no version of Windows is held in much regard.

VS 2008 generated 770 warnings about my insecure strings. I was
converting int, double and int64_t values into text, I believe the
100 char buffer was safe from overflow. But I converted all of them.
The operation would have been easier the _s had the same return value
as the insecure itoa. But the text isn't returned by the function,
so I had to do lots of little surgeries to my application. If this
is, infact, an ISO standard, then Microsoft had to follow the draft
convention, but it could have been easier.

I'm now having trouble with a CreateProcess() call. That's a
topic for a new thread.

As I've said before. I appreciate all the advice you have
given me.

Larry