Would you spend one week changing strcpy to lstrcpyn ?

[Daniel Turini]

I'd spend this same week changing strcpy and static char buffers for std::string. :cool: Yes, even I am blogging now!

[Jim Crafton]

I am surprised nobody else pointed this out. He mentions a C++ app - what the hell is he (they) doing *not* using std::string as opposed to strcpy? :doh: ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned

[GuimaSun]

peterchen wrote: The one who put in the unchecked strcpy's deserves better. The guy that makes those mistakes will not fix the code, cause just an "experienced programmer" will put the hands on it...he will just write "fresh" code :) GuimaSun www.nexsun.com.br NEXSUN TechZone

[GuimaSun]

I love std::string too, but the system was written in pure C (not C++ as I said sorry) and the boss consider C++ slow and unsafe :rolleyes: We could just rename .c to c++ and use extern "c" on WINAPI functions. GuimaSun www.nexsun.com.br NEXSUN TechZone

[Shog9 0]

GuimaSun wrote: the boss consider C++ slow and unsafe Ugh... bounds checking or no, you're doomed.
nOTHING lIES sTILL lONG...

[Jorgen Sigvardsson]

You beat me to it. :) -- Weiter, weiter, ins verderben. Wir müssen leben bis wir sterben.

[Jorgen Sigvardsson]

Ehm.. if you're getting Dr. Watson reports, don't you think the error lies elsewhere than in strcpy()? :~ -- Weiter, weiter, ins verderben. Wir müssen leben bis wir sterben.

[Dale Thompson]

GuimaSun wrote: the boss consider C++ slow and unsafe Oh god. Wonder what he thinks of C#? It sounds like you job isn't gaining you marketable experience anyhow - get the hell out!!! Dale Thompson

[GuimaSun]

When it happens, we get the asm/hex log, which points to the fault address. 90% of them are related to strcpy...hard truth :sigh: GuimaSun www.nexsun.com.br NEXSUN TechZone

[Jorgen Sigvardsson]

Yeah, but strcpy() isn't called by itself, is it? :) -- Weiter, weiter, ins verderben. Wir müssen leben bis wir sterben.

[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!