作者仔细阅读了标准提案文档“ 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地址），可能会将其地址暴露给外界的任何对象都别名。
尽管将整数对指针的转换或从易失性地址中读取指针的结果视为具有“不可知的”出处有时可能会阻碍优化，而这些优化本来是有用的，但这种操作似乎主要发生在指针可以事实表明编译器没有特定理由的“期望”。尽管在某些情况下，编译器会从知道某个对象不会被别名的情况中受益，而尽管其地址已经暴露给外界，但增加了提供此类信息的通用方法（例如，一个参数限定符，指示在函数返回后将不再使用从该参数派生的指针）比仅在“通配符”或“转义填充”指针的上下文中担心更为有用。
大多数编译器，包括基本上所有适用于系统编程的编译器，都将具有某些调用函数的方法，这些函数的确切行为对于编译器或链接器是未知的。因此，他们将需要一些方法来处理从此类函数接收的指针可能源自曾经暴露给外部世界的任何地址（通过作为外部函数的参数传递或存储在全局函数中）的可能性。 -调用外部函数时可访问的对象）。以相同的方式处理其他“逃生舱口”产生的指针会有什么问题？如果对它们进行其他处理，可以获得什么实际的好处？