代码之家  ›  专栏  ›  技术社区  ›  supercat

为什么N2263认为“通配符”或“逃生舱口”出处有问题?

  •  1
  • supercat  · 技术社区  · 6 年前

    阅读标准提案文件“n2263:澄清指针出处v4”( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2263.htm#provenance-escape-hatches-for-io-and-inter-object-arithmetic---and-the-problem-with-wildcards ),作者似乎认为,简单地说编译器不理解的方法产生的指针是不切实际的(例如,执行不寻常的整数计算并将结果转换为指针,或读取 volatile 可能附加到执行指针运算的硬件上的地址可以对其地址已暴露于外部世界的任何对象使用别名。

    尽管将整数到指针的强制转换或从易失性地址读取指针的结果视为具有“不可知”的出处可能偶尔会阻碍本来有用的优化,但这样的操作似乎主要发生在指针实际上可以识别编译器没有的东西的情况下 特别 “期待”的理由。虽然在某些情况下,编译器可以从知道特定对象不会被别名中获益 尽管 它的地址已经暴露给外界,添加提供此类信息的一般方法(例如,参数限定符以指示在函数返回后不会使用从该参数派生的指针)将比仅在“通配符”或“转义图案填充”指针的上下文中担心更有用。

    大多数编译器,包括基本上所有适用于系统编程的编译器,都有一些方法来调用编译器或链接器无法知道其精确行为的函数。因此,它们需要一些方法来处理这样一种可能性,即从这些函数接收的指针可能来自任何曾经暴露于外部世界的地址(通过作为参数传递给外部函数,或者在调用外部函数时存储在全局可访问的对象中)。以同样的方式处理其他“逃生舱口”生成的指针会有什么问题?对他们另眼相看有什么实际好处?

    0 回复  |  直到 6 年前