函数返回局部变量的地址，但它仍然用c编译，为什么？

Question

即使我收到一个警告，一个函数从局部变量返回一个地址，它也会编译。那不是编译器的UB吗？生成的程序集：

    .text
.LC0:
    .asciz "%i\n"
    .globl  foo
    .type   foo, @function
foo:
    pushq   %rbp    #
    movq    %rsp, %rbp  #,
    sub     $16, %rsp   #,
    mov     %rdi, -8(%rbp)   #,
    leaq    -8(%rbp), %rax   #,
# a.c:5: }
    leave 
    ret
    .size   foo, .-foo
    .globl  main
    .type   main, @function
main:
    pushq   %rbp    #
    movq    %rsp, %rbp  #,
# a.c:8:    foo();
    movl    $123, %edi  #,
    call    foo #
    movq    (%rax), %rsi   #,
    leaq    .LC0(%rip), %rdi   #,
    movl    $0, %eax   #,
    call    printf #,
    movl $0, %eax
# a.c:9: }
    popq    %rbp    #
    ret 
    .size   main, .-main
    .ident  "GCC: (Debian 8.3.0-6) 8.3.0"
    .section    .note.GNU-stack,"",@progbits

这里汇编返回局部变量的地址leaq -8(%rbp), %rax，但随后它调用了 instrution leave，这应该使地址“无效” -8(%rbp)（添加了堆栈指针，因此 I 应该不再能够取消引用该地址，因为程序继续）。那么为什么mov (%rax), %rdi当地址返回到%rax不再有效时，它会编译并愉快地取消引用,呢？它不应该是段错误还是终止？

Answer 1

即使我收到一个警告，一个函数从局部变量返回一个地址，它也会编译。那不是编译器的UB吗？

不，但如果是，你怎么知道？您似乎对未定义的行为有误解。这并不意味着“编译器必须拒绝它”、“编译器必须警告它”、“程序必须终止”或任何此类事情。这些确实可能是 UB 的一种表现形式，但如果语言规范需要这种行为，那么它就不会是undefined。 确保 C 程序不执行未定义的行为是程序员的责任，而不是 C 实现。 如果程序员不履行该责任，则 C 实现明确没有相互责任——它可以在其能力范围内做任何事情。

此外，没有单一的“该”C 编译器。不同的编译器可能会以不同的方式做事，但仍然符合 C 语言规范。这就是实现定义的、未指定的和未定义的行为的用武之地。允许这种变化是 C 语言设计者有意为之的。除此之外，它允许实现以对其特定目标硬件和执行环境自然的方式进行操作。

现在让我们回到“不”。这是一个返回自动变量地址的函数的原型示例：

int *foo() {
    int bar = 0;
    return &bar;
}

那应该有未定义的行为呢？函数计算 的地址是明确定义的bar，并且结果指针值具有由函数返回的正确类型。在bar函数返回时 的生命周期结束后，返回值变得不确定（标准的第 6.2.4/2 段），但这本身不会引起任何未定义的行为。

或者考虑一个来电者：

void test1() {
    int *bar_ptr = foo();  // OK under all circumstances
}

正如已经讨论过的，我们的 specificfoo()的返回值总是不确定的，所以特别地，它可能是一个陷阱表示。但这是运行时的考虑，而不是编译时的考虑。即使该值是一个陷阱表示，C 也不要求实现拒绝或无法存储它。特别是，C11 的脚注 50 明确指出了这一点：

因此，可以将自动变量初始化为陷阱表示，而不会导致未定义的行为，但只有在其中存储了适当的值后才能使用该变量的值。

还要注意foo()和test1()可以由编译器的不同运行进行编译，因此在编译时test1()，编译器对foo()超出其原型指示的行为一无所知。C 不会对依赖于程序运行时行为的实现设置转换时间要求。

另一方面，如果稍微修改函数，则陷阱表示的要求将有所不同：

void test2() {
    int *bar_ptr = NULL;
    bar_ptr = foo();      // UB (only) if foo() returns a trap representation
}

如果返回值foo()被证明是陷阱表示，然后存储在它bar_ptr（而不是初始化 bar_ptr与它）产生在运行时未定义的行为。然而，“未定义”再次意味着它在罐头上所说的。C 没有定义任何特定的行为来让实现在这种情况下表现出来，特别是，它根本不要求程序终止或表现出任何外部可见的行为。再说一次，这是运行时的考虑，而不是编译时的考虑。

此外，如果foo()的返回值不是陷阱表示（而是一个不是任何活动对象地址的指针值），那么读取该值本身也没有错，要么：

void test3() {
    int *bar_ptr = foo();
    // UB (only) if foo() returned a trap representation:
    printf("foo() returned %p\n", (void *) bar_ptr);
}

在这方面最大和最常执行的未定义行为是试图取消引用 的返回值foo()，无论是否陷阱表示，几乎肯定不会指向活动int对象：

void test4() {
    int *bar_ptr = foo();
    // UB under all circumstances for the given foo():
    printf("foo() returned a pointer to an int with value %d\n", *bar_ptr);
}

但同样，这是运行时的考虑，而不是编译时的考虑。同样，未定义意味着未定义。只要涉及的函数有作用域内声明，就应该期望 C 实现能够成功转换，尽管一些编译器可能会发出警告，但他们没有义务这样做。函数的运行时行为test4未定义，但这并不意味着程序一定会出现段错误或以其他方式终止。它可能，但我希望在实践中，许多实现所表现出的未定义行为是打印“foo() 返回一个指向值为 0 的 int 的指针”。这样做与 C 的要求并不矛盾。