Jump to content
  • Advertisement
Sign in to follow this  
paulecoyote

strncpy deprecated - Visual C++ 2005 - "Say Goodbye to an old friend"

This topic is 5015 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
*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]

Share this post


Link to post
Share on other sites
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)
Yes, but we like complaining about problems in other people's code, not fixing our own projects ;)
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 phantom
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.
Yes, but they perform different functions (strncpy doesn't always null terminate the string). Otherwise what would be the point of writing a new one?
Quote:
Original post by phantom
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'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..

I guess I'll just globally define _CRT_SECURE_NO_DEPRECATE. So it really isn't that hard to fix, just annoying.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by gosper
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.
But Microsofts implementation of _snprintf doesn't terminate the string either..

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.

Share this post


Link to post
Share on other sites
I just did a quick test on the _snprintf function using visual studio 2003 and it is in fact NULL terminating the buffer.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!