Would you spend one week changing strcpy to lstrcpyn ?

[Member 96]

Nope, but then again I'm the boss so I would probably just make someone else do it if our organization were so brain damaged as to still be coding in anything but .net this century.

---

84 keys are alright with me!

[Atlantys]

I've done worse as a co-op student (intern). Then again, I was just cheap temporary labor. The kindest thing you can do for a stupid person, and for the gene pool, is to let him expire of his own dumb choices. [Roger Wright on stupid people] We're like private member functions [John Theal on R&D] We're figuring out the parent thing as we go though. Kinda like setting up Linux for the first time ya' know... [Nitron]

[realJSOP]

If the code had been written properly to begin with, strcpy wouldn't be giving you headaches. Deal with it and stop whining like a little girl... ------- sig starts "I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

[Todd Smith]

Write your own strcpy and check for bad writes. Todd Smith

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

and they have to use command line GDB to debug it with! :) ¡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

[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