C变量初始化valgrind抱怨

我这里有一个简单的问题。我有一些变量声明如下：

char long_name_VARA[]="TEST -- Gridded 450m daily Evapotranspiration (ET)";
int16 fill_PET_8day=32767;

Invalid write of size 8
==21902==    at 0x408166: main (main.c:253)
==21902==  Location 0x7fe677840 is 0 bytes inside long_name_VARA[0]

==21902== Invalid write of size 2
==21902==    at 0x408178: main (main.c:226)
Location 0x7fe677420 is 0 bytes inside local var "fill_PET_8day"

鉴于上述情况，valgrind对char声明的投诉如下：

char long_name_VARA[]="TEST -- Gridded 450m daily Evapotranspiration (ET)";
int16 fill_PET_8day=32767;

Invalid write of size 8
==21902==    at 0x408166: main (main.c:253)
==21902==  Location 0x7fe677840 is 0 bytes inside long_name_VARA[0]

==21902== Invalid write of size 2
==21902==    at 0x408178: main (main.c:226)
Location 0x7fe677420 is 0 bytes inside local var "fill_PET_8day"

对于int16声明，如下所示：

char long_name_VARA[]="TEST -- Gridded 450m daily Evapotranspiration (ET)";
int16 fill_PET_8day=32767;

Invalid write of size 8
==21902==    at 0x408166: main (main.c:253)
==21902==  Location 0x7fe677840 is 0 bytes inside long_name_VARA[0]

==21902== Invalid write of size 2
==21902==    at 0x408178: main (main.c:226)
Location 0x7fe677420 is 0 bytes inside local var "fill_PET_8day"

我在这里的声明中做错了什么

我还可以不声明这样的字符数组：

char temp_year[5]={0}

---

您引用的警告消息显示无效的内存访问，这些访问恰好命中属于上述两个变量的内存区域。所讨论的变量是错误的受害者，而不是肇事者。这里不应归咎于这些变量。上述声明没有错。这些声明很可能与此处无关

肇事者是

main.c:253

和

main.c:226

上的行，您尚未引用这些行。这就是你的问题所在

---

一个粗略的猜测是，在

fill\u PET\u 8day

（数组？）之后声明了另一个对象。当处理另一个对象时，您会将其内存边界溢出约10个字节，从而导致

fill\u PET\u 8day

和

long\u name\u VARA

的前8个字节溢出。这就是valgrind警告您的问题。

如前所述，声明不是问题所在

尽管仅供参考，但最好将常量字符串声明为

const

const char* long_name_VARA = "TEST -- Gridded 450m daily Evapotranspiration (ET)";

甚至

const char* const long_name_VARA = "TEST -- Gridded 450m daily Evapotranspiration (ET)";

---

这可以防止在代码中修改字符串（以及指针）。

当我运行以下命令时

/* test.c */
#include <stdio.h>

int main(void)
{
    char s[8000000];
    int x;

    s[0] = '\0';
    x=5;
    printf("%s %d\n",s,x);
    return 0;
}

如果我给Valgrind警告的选项，我得到

$ valgrind --max-stackframe=10000000 ./a.out
==1845== Memcheck, a memory error detector
==1845== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1845== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==1845== Command: ./a.out
==1845== 
 5
==1845== 
==1845== HEAP SUMMARY:
==1845==     in use at exit: 0 bytes in 0 blocks
==1845==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1845== 
==1845== All heap blocks were freed -- no leaks are possible
==1845== 
==1845== For counts of detected and suppressed errors, rerun with: -v
==1845== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

---

因此，“无效读/写”是由于没有正确的

--max stackframe=…

选项的大堆栈变量造成的。

什么操作系统？你到底是怎么编的？什么标志？Cent OS 64位和标志是-O3-ansi-ggdb-DLINUX-Df2cFortran-DMEOS-DUM_PGS-DNDEBUG错误与这些声明无关。您引用的消息是补充消息，为valgrind在这些消息之前报告的问题提供附加信息。发布实际的完整错误消息。这些补充文章本身毫无意义。@AnT我编辑了这篇文章，包含了完整的信息

main.c:253

-hmmm。我认为代码中还有一个原因，而不是一些声明。我在这里引用的是与第253行和第266行相关的内容。我在这里引用了相关部分，因为实际代码太长了。然而，valgrind显示了一条警告消息：“==21902==警告：客户端交换堆栈？SP更改：0x7fefff578-->0x7fe677280==21902==若要抑制，请使用：--max stackframe=9995000或更大”@srsci:显然您错误判断了哪些相关，哪些不相关。。。顺便说一句，你是说这些行实际上是第253行和第266行吗？@srsci：你最初的帖子将这些变量显示在一起，彼此相邻。但是行号上说他们实际上相距很远。。。如果看不到更多的代码（或大量猜测），就无法判断这里发生了什么。@srsci：看起来您可能有非常大的堆栈变量，正如Valgrind所建议的那样

——max stackframe=9995000

。