未指定的指针转换在C ++ 14中如何表现? [英] How does an unspecified pointer conversion behave in C++14?

查看:116
本文介绍了未指定的指针转换在C ++ 14中如何表现?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

某些指针强制转换的结果被描述为未指定.例如,[expr.static.cast]/13:

The result of some pointer casts are described as unspecified. For example, [expr.static.cast]/13:

指针指向cv1无效"类型的prvalue可以转换为指针指向cv2 T的类型"的prvalue,[...]如果原始指针值表示内存中字节的地址A,并且A满足T的对齐要求,则所得指针值表示与原始指针值相同的地址,即A.未指定任何其他此类指针转换的结果.

我的问题是:如果不满足对齐要求,可能的结果是什么?

My question is: in the case where alignment is not satisfied, what are the possible results?

例如,是否允许以下​​结果?

For example, are the following results permitted?

  • 空指针
  • 无效的指针值(即不指向大小为T的已分配存储的指针)
  • 指向完全独立的内存部分中的T的有效指针
  • a null pointer
  • an invalid pointer value (i.e. pointer which does not point to allocated storage of size T)
  • a valid pointer to a T in a completely separate part of memory

代码示例供参考:

#include <iostream>

int main(int argc, char **argv)
{
    int *b = (int *)"Hello, world";   // (1)

    *b = -1;                           // (2)
    std::cout << argc << '\n';
}

(1)行触发了我来自[expr.static.cast]/13的上面的引号,因为它是一个reinterpret_cast,由[expr.reinterpret.cast]/7覆盖,该定义以通过void *访问.

Line (1) triggers my above quote from [expr.static.cast]/13 because it is a reinterpret_cast which is covered by [expr.reinterpret.cast]/7 which defines the conversion in terms of static_casting through void *.

如果未指定的结果可能是无效的指针值,则行(1)可能会导致硬件陷阱. (参考: N4430 阐明了与C语言类似的措词++ 14和C ++ 11).

If the unspecified result may be an invalid pointer value, then line (1) may cause a hardware trap. (Reference: N4430 which clarifies similar wording that was in C++14 and C++11).

必然问题:在任何情况下,1行都将导致未定义的行为? (我目前不这么认为;因为C ++ 14无效的指针值读取是实现定义的,否则会导致硬件陷阱.)

Corollary question: is there any case in which line 1 would cause undefined behaviour? (I don't think so at this stage; since C++14 invalid pointer value reading is implementation-defined or causes a hardware trap).

另外有趣的是,由于严格的别名冲突(也许还有其他原因),行(2)在大多数情况下将是未定义的行为,但是,如果未指定的结果可能是&argc,则此程序可以输出-1而不会触发不确定的行为!

Also interesting is that line (2) would in most cases be undefined behaviour due to strict aliasing violation (and perhaps other reasons too), however if the unspecified result may be &argc then this program could output -1 without triggering undefined behaviour!

推荐答案

我的问题是:在不满足对齐要求的情况下,可能的结果是什么?

My question is: in the case where alignment is not satisfied, what are the possible results?

据我所知 N4303:指针安全性和新的放置位置部分地回答了这个问题,尽管有点间接.本文引用了 CWG问题1412:问题指定指针转换会导致对您引用的 [expr.static.cast]/13 的更改,特别是添加:

As far as I can tell N4303: Pointer safety and placement new partially answers this question, although somewhat indirectly. This paper refers to CWG issue 1412: Problems in specifying pointer conversions which brought about the changes to [expr.static.cast]/13 that you reference, specifically adding:

[...]如果原始指针值表示内存中一个字节的地址A,并且A满足T的对齐要求,则所得指针值表示与原始指针值相同的地址,即A [...]其他任何此类指针转换的结果均未指定.[...]

[...]If the original pointer value represents the address A of a byte in memory and A satisfies the alignment requirement of T, then the resulting pointer value represents the same address as the original pointer value, that is, A. The result of any other such pointer conversion is unspecified.[...]

关于此更改,N4303说(强调我的):

在通过DR 1412 [CWG1412]的决议之前,未指定bp的值,该值在其初始化以及随后通过new-expression传递给运算符new的时候. 所述指针可能为空,对齐不充分或使用其他危险.

因此,未指定的转换可能导致:

So an unspecified conversion can results in:

  • 空指针
  • 未充分对齐的指针
  • 使用危险的指针

这篇关于未指定的指针转换在C ++ 14中如何表现?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆