如何禁用_SECURE_ATL宏 [英] How to disable _SECURE_ATL macro

问题描述

亲爱的所有人，

我已将我的源代码从VS 2003升级到VS 2005，并且由于ATL的某些方法中的_SECURE_ATL宏，我的代码是因为
而中断。因为它总是执行
，但是还有一个非安全的代码块

与它一起定义。是否有任何方法可以禁用此宏...仅仅

#define _SECURE_ATL 0，在stdafx.h中或代码之间的某处不是
工作。 />

问候，


-

Ejaz ul Haq

Dear All,
I have upgraded my source code from VS 2003 to VS 2005, and my code is
breaking due to the _SECURE_ATL macro in some methods of ATL. As it is
executed all the times though there is also a non-secure block of code
defined alongwith it. Is there any way of disabling this macro...as mere
#define _SECURE_ATL 0, in the stdafx.h or somewhere between the code is not
working.

Regards,

--
Ejaz ul Haq

推荐答案

：

#ifndef _SECURE_ATL

#define _SECURE_ATL 1

#endif // _SECURE_ATL


atldef.h包含在（其中包括）atlbase.h

你可以添加_SECURE_ATL = 0到项目的预处理器定义

在包含atldef.h之前定义该宏。然而，这导致了大量的警告，因为那时你正在使用减少的功能。


你可以通过添加以下内容来消除这些功能预处理器defs。

_CRT_SECURE_NO_DEPRECATE; _SECURE_SCL = 0; _SECURE_ATL = 0

去除其他已降级函数的警告，添加到顶部

你的StdAfx.h文件


#pragma警告（禁用：4996）


当然，它会很多最好移植你的代码以使用新的，安全的

函数，因为做上面提到的事情会让你开放给b $ b很多潜在的问题。


亲切的问候，

Bruno。


" Ejaz ul Haq" < EJ ******* @ discussions.microsoft.com>在消息中写道

news：58 ********************************** @ microsof t.com ...

from atldef.h:
#ifndef _SECURE_ATL
#define _SECURE_ATL 1
#endif // _SECURE_ATL

atldef.h is included in (among others) atlbase.h
you can add "_SECURE_ATL=0" to the preprocessor definitions of your project
to define that macro before atldef.h is included. that, however leads to a
large number of warnings because then you are using depreceated functions.

you can get rid of those by adding the following to your preprocessor defs.
_CRT_SECURE_NO_DEPRECATE;_SECURE_SCL=0;_SECURE_ATL =0

to get rid of the warnings for other depreceated functions, add at the top
of your StdAfx.h file

#pragma warning(disable : 4996)

of course, it would be MUCH better to port your code to use the new, secure
functions because doing the things mentioned above will leave you open to
lots of potential problems.

kind regards,
Bruno.

"Ejaz ul Haq" <Ej*******@discussions.microsoft.com> wrote in message
news:58**********************************@microsof t.com...

亲爱的所有，
我已将我的源代码从VS 2003升级到VS 2005，并且我的代码由于某些_SECURE_ATL宏而中断了ATL的方法。因为它一直在执行，尽管还有一个非安全的代码块与它一起定义。是否有任何方法可以禁用此宏...仅仅是#define _SECURE_ATL 0，在stdafx.h中或代码之间的某处
不工作。

- Ejaz ul Haq

Dear All,
I have upgraded my source code from VS 2003 to VS 2005, and my code is
breaking due to the _SECURE_ATL macro in some methods of ATL. As it is
executed all the times though there is also a non-secure block of code
defined alongwith it. Is there any way of disabling this macro...as mere
#define _SECURE_ATL 0, in the stdafx.h or somewhere between the code is
not
working.

Regards,

--
Ejaz ul Haq

" Bruno van Dooren" <峰; br ********************** @ hotmail.com>写了

"Bruno van Dooren" <br**********************@hotmail.com> wrote

你可以通过在你的预处理器中添加以下内容来摆脱它们。
_CRT_SECURE_NO_DEPRECATE; _SECURE_SCL = 0; _SECURE_ATL = 0
<为了摆脱其他失效函数的警告，请在StdAfx.h文件的顶部添加

#pragma warning（disable：4996）

you can get rid of those by adding the following to your preprocessor
defs.
_CRT_SECURE_NO_DEPRECATE;_SECURE_SCL=0;_SECURE_ATL =0

to get rid of the warnings for other depreceated functions, add at the top
of your StdAfx.h file

#pragma warning(disable : 4996)

of course, it would be MUCH better to port your code to use the new,
secure functions because doing the things mentioned above will leave you
open to lots of potential problems.

<我完全，完全和完全不同意这种说法。

几乎所有这些都是有代价的。在安全的C库中有一些确实是合理的：


- 返回内部缓冲区的函数（例如tmpnam）或其他

需要内部缓冲区（特别是qsort）

- 将不可预测的数据量写入缓冲区的函数

（具有特定格式字符串的scanf）


但是，有些地方你通常会完全清楚缓冲区大小的
。例如，弃用memcpy支持

memcpy_s是一个非常愚蠢的动作，恕我直言。


标准C ++库的情况更糟（VC ++使用

首字母缩略词SCL - 你怎么知道不是标准

C图书馆？我不知道）。

它们会对性能和工作集产生重大影响。

更糟糕的是，一些安全功能违反了C ++标准的要求

，这实际上可能会引入安全问题

原始代码中没有（授予，这是不太可能的）。

然后就是_SECURE_SCL_THROWS，这可能比疾病更糟糕了。

当然，安全SCL也是如此。没有捕获所有相关的安全性

错误 - 事实上我不认为我曾经在一个应用程序中看到过一个问题我们在_SECURE_SCL帮助下运送了b $ b。


底线：安全SCL是有代价的，我相信

这些权衡与C ++

语言的理念并不完全吻合。从来没有定义_SECURE_SCL_THROWS = 1

，除非你完全知道你在做什么。


-hg

FWIW, I completely, entirely and utterly disagree with that statement.
Almost all these come at a price. There are some things that are indeed
reasonable in the secure C library:

- functions that return internal buffers (e.g. tmpnam) or otherwise
require internal buffers (notably qsort)
- functions that write unpredictable amounts of data to a buffer
(scanf with certain format strings)

However, there are places where you''re typically perfectly aware
of the buffer size. For instance, deprecating memcpy in favor of
memcpy_s is a quite stupid motion, IMHO.

Things are worse for the Standard C++ Library (VC++ uses the
acronym SCL for it - how do you know the don''t mean Standard
C Library? I don''t know).
They can have significant impact on performance and working set.
Worse, some of the "secure functionality" violate the requirements
of the C++ standard, which could in fact introduce security issues
not present in your original code (granted, this is quite unlikely).
And then there''s _SECURE_SCL_THROWS, which is probably
worse than the disease.
Of course, the "Secure SCL" does not catch all security relevant
bugs - in fact I don''t think I''ve ever seen an issue in an app we
shipped where _SECURE_SCL had helped.

Bottom line: The "Secure SCL" comes at a price and I believe
the tradeoffs don''t fit nicely with the philosophy of the C++
language. And never ever defined _SECURE_SCL_THROWS=1
unless you absolutely know what you''re doing.

-hg

但是，有些地方你通常完全了解缓冲区大小。例如，弃用memcpy以支持
memcpy_s是一个非常愚蠢的动作，恕我直言。

However, there are places where you''re typically perfectly aware
of the buffer size. For instance, deprecating memcpy in favor of
memcpy_s is a quite stupid motion, IMHO.

memcpy的问题是，如果你正在与代码交互你自己没有写b
$ b你不能确定使用它是否安全。

在这些情况下总是更好使用memcpy_s是因为你必须

再次验证所有外部缓冲区。


除非我们谈论的是一些代码，其中性能是

很关键，我建议使用新的库，因为它们更安全，而在99.9％的情况下，增加的CPU周期并不重要。


如果性能真的很重要那么这可能是使用

非安全功能的原因，但这不应该是默认选择。对于大多数

（但不是全部）代码，安全性和

稳定性问题比性能问题更常见。


亲切的问候，

布鲁诺。

the problem with memcpy is that if you are interacting with code that you
didn''t write
yourself, you cannot be sure that using it is safe.
in those cases it is better to always use memcpy_s because you have to
verify with all external buffers anway.

unless we are talking about some piece of code where performance is
critical, i would advise to use the new libaries because they are much
safer, and in 99.9 % of the cases, the added CPU cycles are un-important.

if performance really is critical then that could be a reason for using the
un-safe functions, but that shouldn''t be the default choice. security and
stability issues are much more commonplace than performance issues for most
(but not all) code.

kind regards,
Bruno.

这篇关于如何禁用_SECURE_ATL宏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！