strncpy deprecated - Visual C++ 2005 - "Say Goodbye to an old friend"
Author
So I was compiling something in Visual C++ 2005 just now and I have a this warning pop up:
warning C4996: 'strncpy' was declared deprecated
Message: 'This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'
So I go to the help and look up what is going on, and it directs me here...
MSDN Link
... so basically MS have recommended a change to the core libraries, and gone ahead and implemented it anyway in their latest release. Classic MS move.
Anyway is anyone actually using these new functions appended with _s? (eg strncpy_s). It strikes me that using them makes your code platform, or even compiler / library specific.
Anyone aware of any progress since then? I realise this has probably been brought up before (not seen recently myself) but I was wondering if anything new recently has happened with that stuff?
Can't say I'll miss strncpy, it was pretty useless and horribly misleading to begin with. But the deprecation fopen is just plain annoying, why can't they place errno in thread-local storage or do whatever GCC did?.
I can't quite figure out why it's started to complain about certain std::copy calls either..
I guess we'll just have to disable the warnings for now, using the alternative versions just isn't an option if you want to write portable code.
I can't quite figure out why it's started to complain about certain std::copy calls either..
I guess we'll just have to disable the warnings for now, using the alternative versions just isn't an option if you want to write portable code.
*chuckles* I find it intresting that MS gets moaned at for insecure software and yet, when they do something to help fix the problem they still get moaned at [grin] (this is probably part of the motivation for giving away the EE of VS05 as well)
As for the functions, are there any differences between the signatures of strncpy and strncpy_s ? If not then the solution would seem to me to be either (a) #define trickery based on platform or (b) assign the correct one to a function pointer on start up.
If the call signature is different then I guess you'll have to find a way to seperate out the functions or call sites for them into seperate modules and let your build system only build the right one, as you would any platform dependant code.
@doynax
There is a 'safe' version of std::copy and other functions as well iirc, you'll want to check Washu's journal as that has a nice entry on the safe std. lib stuff [smile]
As for the functions, are there any differences between the signatures of strncpy and strncpy_s ? If not then the solution would seem to me to be either (a) #define trickery based on platform or (b) assign the correct one to a function pointer on start up.
If the call signature is different then I guess you'll have to find a way to seperate out the functions or call sites for them into seperate modules and let your build system only build the right one, as you would any platform dependant code.
@doynax
There is a 'safe' version of std::copy and other functions as well iirc, you'll want to check Washu's journal as that has a nice entry on the safe std. lib stuff [smile]
Quote:Original post by phantomYes, but we like complaining about problems in other people's code, not fixing our own projects ;)
*chuckles* I find it intresting that MS gets moaned at for insecure software and yet, when they do something to help fix the problem they still get moaned at [grin] (this is probably part of the motivation for giving away the EE of VS05 as well)
Besides, you should expect to get bashed for any 'breaking' changes.
So don't go around deprecating the standard library until ANSI says so..
Quote:Original post by phantomYes, but they perform different functions (strncpy doesn't always null terminate the string). Otherwise what would be the point of writing a new one?
As for the functions, are there any differences between the signatures of strncpy and strncpy_s ? If not then the solution would seem to me to be either (a) #define trickery based on platform or (b) assign the correct one to a function pointer on start up.
Quote:Original post by phantomI'm aware of the safe standard library, and Microsofts has had it for ages. But it's still a major pain for those of us wanting to write portable code..
There is a 'safe' version of std::copy and other functions as well iirc, you'll want to check Washu's journal as that has a nice entry on the safe std. lib stuff [smile]
I guess I'll just globally define _CRT_SECURE_NO_DEPRECATE. So it really isn't that hard to fix, just annoying.
Well, the change isnt really 'breaking', your code still compiles, but unless you tell them you know what you are doing its going to warn you about it.
Its just MS trying to enforce safe coding on their platform and considering the amount of flakk they get when stuff breaks due to poor coding who can blame them?
Its just MS trying to enforce safe coding on their platform and considering the amount of flakk they get when stuff breaks due to poor coding who can blame them?
Author
Quote:Original post by phantom
*chuckles* I find it intresting that MS gets moaned at for insecure software and yet, when they do something to help fix the problem they still get moaned at [grin] (this is probably part of the motivation for giving away the EE of VS05 as well)
Yeah. I'm not moaning, more of concerned. Stuff still compiles and everything, just new warnings. I don't want to start coding down this route and not have their prestandard rejected or something. The article says something about a similar unix initative that didn't go "quite far enough". I guess the standards body are moving too slowly for MS that just wants to get stuff done and out the door, so they are taking the risk. So do we follow MS and bet that these new functions will become part of the standard?
Quote:Original post by phantom
As for the functions, are there any differences between the signatures of strncpy and strncpy_s ?
Yep there are, strncpy_s takes 4 params, stncpy takes 3. MSDN has details.
I'll have to check out Washu's journal, I confess not really looked for a few weeks at it.
What I'm working on at the moment is Win32 anyway, and I've not got any plans for it to be anywhere else. But there are other projects I am working on that it might be nice to work on cross platforms, like my Ogre sound extension stuff for example.
It's nice they only warn you and tell you how to turn the rules off, rather then just making breaking changes. MS is much nicer about such things these days!
Quote:Original post by paulecoyote
Yep there are, strncpy_s takes 4 params, stncpy takes 3. MSDN has details.
You could still use some macro trickery (though it might go from trickery to downright code abuse) to get around the warning.
I personally use strncpy a lot in my current project (it needs looking at, but I will prob stick with it), so I would probably go down this route.
Spree
Probably because strncpy doesn't NULL terminate the destination buffer. You have to do that manually. That could leed to a buffer overflow or a memory leek somewhere down the line. _snprintf is a better alternative.
Quote:Original post by gosperBut Microsofts implementation of _snprintf doesn't terminate the string either..
Probably because strncpy doesn't NULL terminate the destination buffer. You have to do that manually. That could leed to a buffer overflow or a memory leek somewhere down the line. _snprintf is a better alternative.
I suggest writing safe wrappers for these functions (watch out for strncat too) yourself, perhaps even invoking the safe versions directly on platforms that has them.
I just did a quick test on the _snprintf function using visual studio 2003 and it is in fact NULL terminating the buffer.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
