|
Boost : |
Subject: Re: [boost] [new Warnings policy] MS C4180 on the Maintenance Guidelines
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-11-23 18:03:15
On Mon, Nov 23, 2009 at 3:24 PM, Patrick Horgan <phorgan1_at_[hidden]> wrote:
> Zachary Turner wrote:
>
>> On Mon, Nov 16, 2009 at 3:08 PM, Patrick Horgan <phorgan1_at_[hidden]>
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk