当前位置导航:炫浪网>>网络学院>>编程开发>>C++教程>>C++进阶与实例

保卫C++:安全STL编程中的受检迭代子

      C++语言、STL、标准C++库,相比之C语言及C运行时库(CRT)而言,更加现代、也更加健壮。正因为软件的安全性与健壮性息息相关,所以在安全性方面,标准C++比C及CRT面临的问题更少,那也就不足为奇了。然而,在标准C++中,仍存在一些漏洞,而且,Visual C++ 2005中的一项新增功能,使这个所谓的“循环漏洞”更加容易被忽视。

      STL在横向集合中,大量使用了迭代子(iterator),对迭代子不正确的使用,一般可以两种主要的方式表现出来:

      ·使用已被集合修改为无效的迭代子

      ·使用迭代子试图访问集合范围之外的一个元素

      以下的代码演示了这两种问题:

    //使用一个无效的迭代子

    vector vec;
    vec.push_back(1);
    std::vector::iterator it = vec.begin();
    vec.push_back(2);
    std::cout<<*it;
    //试图访问迭代子范围之外
    vector emptyVec;
    std::vector::iterator emptyIt = emptyVec.begin();
    int i = *emptyIt;
      如果在Visual C++ 2005中,以Debug方式来构建上述代码,这两种情况都会引发断言错误,所以要找到错误所在,并不是很难;如果以Release方式来构建,将不会捕捉到对无效迭代子的使用,但仍会捕捉到对集合外部数据的访问。原因在于,Debug构建基于Visual C++中被称为“调试迭代子支持”的那一部分,其是通过在运行时库源代码中进行检查来实现的,而在默认情况下,Debug构建时是打开“调试迭代子支持”的,但你也能通过把符号_HAS_ITERATOR_DEBUGGING定义为一个零值来关闭它。

      “调试迭代子支持”——其主要集中在代码正确性上,与之形成对比的是,Release构建概念中的受检迭代子,其主要集中在防止程序运行中的安全问题。当有错误发生时,受检迭代子通常产生一个运行时错误,默认情况下会终止程序,而不是抛出一个断言。一般来说,可以有两种方法来处理由受检迭代子产生的错误:

      ·调用_set_invalid_parameter_handler,来设置一个非法参数处理程序。

      ·定义_SECURE_SCL_THROWS为1,其在抛出时导致一个异常。

      另外,为强制Visual C++与C++标准保持一致,并且不对迭代子进行检查,你可以把_SECURE_SCL定义为零。

      受检查迭代子适用于大多数STL容器类中的[ ]操作符,front和back方法;正因为算法在STL中扮演了一个重要的角色,所以与受检迭代子进行集成,无疑对它们来说显得至关重要。而在Microsoft安全部署中,最重要的一点就是,编译器要在默认情况下打开安全选项,这也是受检迭代子与STL算法中这些迭代子的使用情况。对一个使用了受检迭代子的程序而言,所有对标准算法函数的调用,都会导致一个安全函数被调用,这意味着,如果调用一个std::merge,将会转发至stdext::checked_merge。而在STL算法中,这些加有checked_ 前缀的版本防止了未受检的迭代子,当使用第三方且是未用Visual C++ 2005重新编译过的的组件时,就可以捕捉到这些未受检迭代子了,任何试图传递一个未受检迭代子到受检算法中的代码,都不会通过编译。

      Visual C++的安全增强与语言标准

      在以前,Microsoft公司为了其自己的种种商业利益,在很长一段时间里忽视或暗中搅乱C++语言的标准化进程;如今,Microsoft在许多的标准实体中,都扮演了一个重要且有帮助性的角色,作为一家在C++方面投资最大的公司,参与到“标准化”这个游戏当中来,无疑非常引人注目。

      C++/CLI如今已是一个ECMA标准,这意味着(如同标准C++一样),任何编译器开发商都可以构建一个C++/CLI语言编译器。一个特定的C++/CLI编译器可能会专注于CLR或一个完全不同的环境,如Java的运行时库;另外,对C++/CLI的反对声音,宣称因为基于C++/CLI与标准C++太过于不同,因此需要另外一个不同的名字。争论的核心在于“C++/CLI已发展成为一个差不多、但又不完全不像我们所知的C++的语言,语法、语义、术语及底层对象模型,都大不相同。”但这个反对声音并不奏效,如今C++/CLI已是一个完整版本的语言了。

      当前,Microsoft仍通过C标准化过程,着手对CRT的安全性进行修改,如果且当这些修改被认可,及Visual C++ 2005中带 _s后缀的函数与Visual C++合成一体时,那么使用CRT编写可移植及更安全的代码,就不再是空中楼阁了。

      最后,在Visual C++ 2005中并没有强制使用这些安全扩展或C++/CLI,如果你喜欢设置不同的#define,或者在某些情况中忽略编译器的警告,那么,纯净、无瑕疵的C/C++代码就正在向你招手。

 

相关内容
赞助商链接