Would you spend one week changing strcpy to lstrcpyn ?

[Nemanja Trifunovic]

Maybe the implementation they use is recursive :eek:

---

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

[Michael Dunn]

If strcpy() calls are generating crashes, it means your copies are overwriting the stack. This is a security risk. Unchecked strcpy() calls lead to buffer overflow attacks. If your boss doesn't want to fix numerous security holes, I would feel very worried if I were a user of that software. -- I'm Michael Dunn and I approve this post. Vote Trogdor in oh-four!

[m_mond]

Which is why you use strncpy... There's a very simple way to avoid basic stack overflows built in to the language. It still blows my mind that people still don't use the 'n' string and memory function. On the other hand, this is also a case for using string objects of some sort. That's something worth spending the time to fix, IMO.

[peterchen]

won't help with stack buffers.

---

we are here to help each other get through this thing, whatever it is Vonnegut jr.
boost your code || Fold With Us! || sighist | doxygen

[Alvaro Mendez]

I recommend a couple of things: 1. Don't use regular strncpy -- it has it's own problems. Use your own function, similar to this:

char* STRNCPY(char* szTarget, const char* szSource, unsigned sizeOfTarget)
{
assert(szTarget);
assert(szSource);
assert(sizeOfTarget);

strncpy(szTarget, szSource, sizeOfTarget - 1);
szTarget[sizeOfTarget - 1] = 0;

return szTarget;
}

2. Create a macro for copying into string buffers that calls the above function:

#define STRCPY(szTarget, szSource) STRNCPY(szTarget, szSource, sizeof(szTarget))

Then you can replace all cases where you have this type of code:

char buffer[100];
....
strcpy(buffer, someText);

with

char buffer[100];
....
STRCPY(buffer, someText);

This ensures you only copy no more than 99 (size - 1) characters into the buffer plus the null terminator. Regards, Alvaro

---

Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. - George W. Bush

[Jeremy Falcon]

So you honestly believe anyone not coding in .NET is brain damaged? Do you really have a view of the programming world or not? .NET is a great replacement for VB and it's nice for business/data driven apps. But, I wouldn't want a diver or a game (amongst other things) written in .NET. BTW, just throwing off responsibility for a screw up to someone who's not at fault just because you don't feel like doing it makes you a bad boss IMO. Also, the captain goes down with the ship, so if somebody is brain dead and screws up, it's ultimately your fault anyway because you're the boss. Jeremy Falcon

[Jorgen Sigvardsson]

:laugh: That is certainly possible! :-D -- Weiter, weiter, ins verderben. Wir müssen leben bis wir sterben.

[Matt Gerrans]

Isn't it great to have a boss who once programmed 20 or 30 years ago and knows the one true path? Talk about premature optimization! Don't let him find out about how much the multitasking OS is cutting into the app's performance, or you'll be forced into writing your app in assembly as a BIOS extension. Matt Gerrans

[GuimaSun]

Great. Definitively, as your assert suggests, more than 50% of c/c++ code worldwide are deployed on debug mode :-D Tx. GuimaSun www.nexsun.com.br NEXSUN TechZone

[Michael Dunn]

Actually lstrcpyn() is better than strncpy() because lstrcpyn() always leaves the string null-terminated. With strncpy() you have to do that yourself if the source string length was >= destination buffer length. -- I'm Michael Dunn and I approve this post. Vote Trogdor in oh-four!

[nfleming]

Since you are on windows, install the CRT hooks, or just attach a debugger, set break on access vio, and see where it fires. strcpy, check the stack and see how you got there. Treat the cause, not the symptom. It is probably easier and more cost effective, and it is the right thing to do.

[afinnell]

So you honestly believe anyone not coding in .NET is brain damaged? Do you really have a view of the programming world or not? .NET is a great replacement for VB and it's nice for business/data driven apps. But, I wouldn't want a diver or a game (amongst other things) written in .NET. I tend to agree with your statement but not your points you use to make up your statement. The same reasons where given when moving from Assembly to C, then again from C to C++. They are already developing games in C# and if .NET could be ran at the kernel level I'm sure people would develop drivers with it. So those points are not valid. That being said just assuming that a business has a choice to develop with .NET is another thing. Based on the shear number of strcpy's he has to replace it would appear it's a fairly mature application which means the decision for C++ was made a while ago. Rewriting an entire application in a different language without a business (a.k.a. customer) reason is a very bad mistake. Also I don't even think the original poster made a reference to the platform the application was written on. This could be Solaris for all we know. I do believe they should replace all the strcpy's with the parameterized version and be lashed so they never use the bad version again. - Drew

[afinnell]

the boss consider C++ slow and unsafe I've met people like this. There is very little hope in convincing them of doing the product correctly. You have a choice, put up or shut up. Depending on what needs to be done you need to convince upper management and the customer that they can get a better ROI by using a moderm language such as C#. Maintainability, and code reuse alone will save quite a bit of time and time equals money. - Drew

[Jeremy Falcon]

Yeah, they have managed DirectX and from what I understand it's slower - just like every iteration of a Microsoft release. And, since you can't write drivers in .NET then my point about that was valid. You said so yourself. Jeremy Falcon