递增指针是否发生在 C

您传递给 abc() 的值指向未初始化的内存。您必须为要存储的三个结构体留出 @H_237_5@malloc 空间。否则，取消引用它是未定义的行为。在我看来，您的目标是让 k 成为一个包含 3 个指向结构的指针的数组。如果是这种情况，您应该像这样声明：

struct abc **k = (struct abc **)malloc(sizeof(struct abc *) * 3);

这应该在 32 位系统上分配 12 个字节（每个指针 4 个），或在 64 位系统上分配 24 个字节（每个指针 8 个）。

由于 k 现在是一个指向指针的指针，而不仅仅是一个指针，因此在调用 abc() 时不再需要获取其地址，因此下一行变为：

abc(k);

在 abc 函数中，您不应该手动将值增加到指针。这就是 [] 运算符的用途。您还应该手动将字符串转换为 char*。进行这些更改后，您的 abc 函数应如下所示：

void abc(struct abc **t1){
    t1[0]=(struct abc *)malloc(sizeof(struct abC));
    t1[0]->c=(char *) "Hello";
    
    t1[1]=(struct abc *)malloc(sizeof(struct abC));
    t1[1]->c=(char *) "cool";
    
    t1[2]=(struct abc *)malloc(sizeof(struct abC));
    t1[2]->c=(char *) "Super cool";
}

注意 t1[0] 和 *t1 如何做同样的事情。后者应始终与数组一起使用，以明确 t1 实际上是一个数组。

您应该在 printf() 调用中进行类似的更改，使它们看起来像这样：

printf("%s\n",k[0]->c);
printf("%s\n",k[1]->c);
printf("%s\n",k[2]->c);

最后，你应该总是释放你的 malloc 内存！首先释放数组中的每个指针：

free(k[0]);
free(k[1]);
free(k[2]);

然后释放数组本身：

free(k);

养成始终释放数据的习惯将非常有助于防止大型程序中出现痛苦的内存错误。

毕竟，你的最终程序应该是这样的：

#include <stdio.h>

struct abc {
    char *c;
};

void abc(struct abc **t1);

int main() {
    struct abc **k = (struct abc **)malloc(sizeof(struct abc *) * 3);
    abc(k);
    
    printf("%s\n",k[0]->c);
    printf("%s\n",k[1]->c);
    printf("%s\n",k[2]->c);
    
    free(k[0]);
    free(k[1]);
    free(k[2]);
    
    free(k);

    return 1;
}

void abc(struct abc **t1){
    t1[0]=(struct abc *)malloc(sizeof(struct abC));
    t1[0]->c=(char *) "Hello";
    t1[1]=(struct abc *)malloc(sizeof(struct abC));
    t1[1]->c=(char *) "cool";
    t1[2]=(struct abc *)malloc(sizeof(struct abC));
    t1[2]->c=(char *) "Super cool";
}

为了回答您的最后一个问题，段错误的行为和时间可能是一件非常棘手且不可预测的事情。它们通常是由未定义的行为引起的，在同一程序的不同执行之间，这些行为甚至可能不同。您应该知道的是，程序中发生段错误的位置与内存中发生的位置无关。

分配方法是正确的，但是，您忘记了初始化 k，因此 k 是一个悬空指针。这就是您出现分段错误的原因。我通过添加一个编译器将初始化的变量来应用一个简单的“脏”修复，只是为了证明这是问题所在。

#include <stdio.h>
#include <stdlib.h>

struct abc{ char *c;};

void abc(struct abc **t1);

int main() {
    struct abc _abc[2],*k;
        k = &_abc[0];
    abc(&k);
    printf("%s\n",k->c);

    printf("%s\n",k->c);
    printf("%s\n",(k+1)->c);
    //printf("%s\n",(k+2)->c);

    return 1;
}

void abc(struct abc **t1){


    *t1=(struct abc *)malloc(sizeof(struct abc ));
    (*t1)->c=malloc(50);
    sprintf((*t1)->c,"Hello");
    *(t1+1)=(struct abc *) malloc((sizeof(struct abc )));
    (*t1+1)->c=malloc(50);
    sprintf((*t1+1)->c,"cool");
    *(t1+2)=(struct abc *) malloc((sizeof (struct abc )));
    //(*t1+2)->c="Super cool";
}

编译后

~$ gcc memtest.c -o memtest
~$ ./memtest
Hello
Hello
cool

要了解为什么在 @H_237_5@main 中出现分段错误，而在 abc 中没有，您需要在汇编程序 gcc test.c -S -ggdb3 中转换示例。就我而言，在 ARM64 上，k 被优化掉了。在调用 abc() 之前，编译器插入一个 __stack_chk_guard。这是汇编中的段（ARM64）

    .arch armv8-a
    .file   "memtest_bug.c"
    .text
.Ltext0:
    .align  2
    .global main
    .type   main,%function
main:
.LFB6:
    .file 1 "memtest_bug.c"
    .loc 1 8 16
    .cfi_startproc
    stp x29,x30,[sp,-32]!
    .cfi_def_cfa_offset 32
    .cfi_offset 29,-32
    .cfi_offset 30,-24
    mov x29,sp
    .loc 1 8 16
    adrp    x0,:got:__stack_chk_guard
    ldr x0,[x0,#:got_lo12:__stack_chk_guard]
    ldr x1,[x0]
    str x1,24]
    mov x1,0
    .loc 1 10 9
    add x0,sp,16
    bl  abc

当abc()被调用时，k指向一个属于进程的内存区域，所以它仍然是一个有效的段，不会产生段错误。当 main 完成时，编译器插入一个代码来检查堆栈保护，如果检查失败，它会调用 __stack_chk_fail。

    mov x3,0
    beq .L3
    bl  __stack_chk_fail
.L3:
    mov w0,w1
    ldp x29,[sp],32
    .cfi_restore 30
    .cfi_restore 29
    .cfi_def_cfa_offset 0
    ret
    .cfi_endproc

此代码检测内存守卫的故障并生成分段错误。这是产生故障时的堆栈（在ARM64上）

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x0000fffff7e7cd68 in __GI_abort () at abort.c:79
#2  0x0000fffff7eca29c in __libc_message (action=action@entry=do_abort,fmt=fmt@entry=0xfffff7f89f58 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x0000fffff7f3c600 in __GI___fortify_fail (msg=msg@entry=0xfffff7f89f40 "stack smashing detected") at fortify_fail.c:26
#4  0x0000fffff7f3c5d4 in __stack_chk_fail () at stack_chk_fail.c:24
#5  0x0000aaaaaaaaa8e4 in main () at memtest_bug.c:18