Irregardless if it's a Microsoft prank or whatever - they're safer than normal CRT functions and they're easy to do away with if you need portability.
Plus, they can help you find bugs, especially when you write complicated code and pass a destination buffer not large enough to hold the data.
Portability isn't an issue if you understand what you're doing. Usong Windows APIs and such is non-portable since they must be completely re-written, but "secure" functions only needs a wrapper or a define to wrap them to standard functions, so there's no issue here.
If it's Microsoft only, then they have done us a great service in at least trying to provide a better runtime library without breaking too much code. I don't blame them and I certainly don't mind using them.
They're dumb...
Er... use strncpy()...Originally Posted by msnd pointlessness
They don't seem to be more 'secure', in fact they're merely n00b-friendly CRT functions. They even 'fix' gets() so you can use it 'safely'. Pfft, it's been established for a long time that they're unsafe and use the other CRT functions which already solve the problem (eg, gets() -> fgets(), strcpy() -> strncpy(), etc). M$ has done nothing but launched an attempt to break portability a bit more.
Last edited by zacs7; 12-25-2007 at 06:53 PM.
And as I said before, strcpy() is safe if you're not careless.
malloc() the buffer for what you need and guarentee the size will match. Otherwise, use static buffers, but make sure your static buffer being copied into is large enough to handle the entire buffer coming in. Bingo. Your buffer is large enough.
Even the MS 'secure' functions can be insecure if you don't know how to use them properly. Just pass in the wrong size for a buffer size and boom!
I avoid C like the plague, so I usually don't need to use those functions, but when I do use them, I read the docs thoroughly. The reason why they can be insecure is because people don't pay enough attention to the docs.