Microsoft are really losing it

[ewx]

XXXXX.c(118) : warning C4996: 'fopen' was declared deprecated
        c:\program files\microsoft visual studio 8\VC\include\stdio.h(234) : see
declaration of 'fopen'
        Message: 'This function or variable may be unsafe. Consider using fopen_
s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help
 for details.'

Comments

[pjc50.livejournal.com]

Why is this? Is it due to the behaviour of fopen("CON:", ...) or something?

[ewx.livejournal.com]

They've crapped on a whole bunch of standard functions in the same way. In some cases it's fair enough, e.g. sprintf() and strcpy(), but fopen()? Come on.

[simont]

A brief google turns up "Security Enhancements in the CRT", which is depressingly generic: it just gives a list of reasons why a function might be worth replacing with a secured version, but doesn't list for each individual function why they did.

"Security-Enhanced Versions of CRT Functions" really ought to give a more detailed breakdown, but mysteriously doesn't.

And even fopen_s's own page ducks the issue, saying nebulously that it contains "security enhancements as described in" the first page. Arrgh!

Doing a visual diff between fopen_s's page and fopen's page suggests that the two relevant differences are that fopen_s (a) does not open files in sharable mode by default (whereas fopen's page leaves it unspecified whether it does this), and (b) validates its input parameters to ensure they're neither NULL nor the empty string, and returns an errno value if they are, rather than segfaulting. I suppose they might not have wanted to do (a) by means of a quiet change to the existing function's behaviour, because there will probably have been people relying on that behaviour.

All in all, not an impressive effort of documentation, let alone a good reason to deprecate one of the most standard C library functions in existence!

[ewx.livejournal.com]

I suspect it to be no more than fire and motion (http://www.joelonsoftware.com/articles/fog0000000339.html).

[emperor]

That article *so* describes my working habits :-(

[covertmusic.livejournal.com]

It's not just you. It's most people I know here.

It's *entirely* me.

[hairyears.livejournal.com]

It's all a horrible plot to railroad you onto .Net

[sparrowsion]

Time for a swift #pragma warning ( disable : 4996 ) (to go with all the others).

[ewx.livejournal.com]

That's what I've ended up with. But there are logo requirements concerning this stuff, it seems...

[bellinghman.livejournal.com]

The ISO Standards Committees were spitting feathers over Microsoft when they did this, and were thinking of declaring the resulting compilers to be not C (or not C++, as appropriate).

[womble2.livejournal.com]

The Microsoft C/C++ compiler for Win32 only implements C95, which of course is no longer standard C. For Win64 it defines size_t and ptrdiff_t as aliases for types that don't exist in C95 (or C++98), do it doesn't support any version of the standard languages.

[womble2.livejournal.com]

I doubt that, unless they've recently changed. Logo requirements are generally about such things as running with normal user rights, not breaking Terminal Services, and so on. The "deprecation" actually refers to Microsoft's internal coding standard; this bug report indicates the message and warning level have been revised (http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101187).