On Mon, Nov 23, 2009 at 3:24 PM, Patrick Horgan <phorgan1@gmail.com> wrote:
Zachary Turner wrote:
On Mon, Nov 16, 2009 at 3:08 PM, Patrick Horgan <phorgan1@gmail.com> wrote:
... elision by Patrick ...
C4996 Microsoft deprecated these functions on their own (and they call
themselves POSIX compliant), and replaced them with extremely dangerous replacements that they claim are safe. The replacement functions are non-POSIX and aren't available from other compilers, hence non-portable. These warnings should be suppressed. I believe that you can also suppress by defining _CRT_NONSTDC_NO_DEPRECATE before and undef'ing after to do a local suppression.
Somewhat off topic, but why exactly are these extremely dangerous, and not secure?
Sorry about the delay in responding to this, but Nick Stoughton says it much better than I do, so I was waiting for him to get back to me and let me know if I could just quote him on it. Nicely enough, he did, so the following is from him, it's the original liaison memo from POSIX to C when C was considering a proposal to add these interfaces into the lib:
Nick Stoughton wrote:
SC 22/WG 14 N1160 Austin Group Concerns on PDTR 24731 Stoughton 2006-02-27 Members of the Austin Group have been reviewing the proposed Technical Report on "Bounds Checking Functions" over the last year, and wish to express their concerns over its direction.
... snipped for brevity What follows after the snipped part I find to be a rather strange argument. I mean I get that there's added complexity and that added complexity is "bad", but the proposed "solution" requires that the programmer be ok with the memory being allocated by the CRT, which is grossly limiting and kind of against everything that C / C++ is about. Zach