GCC：条件判断中赋值语句和函数结尾时无返回值的警告

　　有下面非常经典的一个字符串复制程序。

　　test1.c

#include <stdio.h>
int main()
{
    char str_t[]="This String comes from t";//初始化字符数组
    char str_s[]="This is an empty string  ";//初始化字符数组
    char *t=str_t;//初始化字符指针
    char *s=str_s;//初始化字符指针
    while(*s++=*t++)//*的优先级比++高，且为右结合，因此会将t的值逐个赋值给s，直到结果为'\0'
        ;
    printf("%s\n%s\n",str_t,str_s);
    //此处省略了返回值
}

　　先用$gcc test1.c编译。编译成功，无提示。再用检查地更严格的-Wall选项试一试。

　　$gcc test1.c -Wall

　　编译器提示如下：

$ gcc test1.c -Wall
test1.c: In function ‘main’:
test1.c:8:2: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
  while(*s++=*t++)//*的优先级比++高，且为右结合，因此会将t的值逐个赋值给s，直到结果为'\0'
  ^
test1.c:12:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

　　我们逐个进行分析。

　　首先是 warning: suggest parentheses around assignment used as truth value （警告：建议在赋值语句周围使用小括号来表明“真值”）。这是因为我们有语句while(*s++=*t++)，在这种情况下，程序员实在是太容易把=和==弄混了。我曾经有一个程序调试了很久都没有发现错误，直到最后发现了这样一个错误：

　　while(s=‘\n’)

　　　　...;

　　在这种情况下，除非s总是等于'\n'这个非零值，因此除非while内部有跳转语句，这将会是一个死循环。GCC之所以在这里发出警告就是这个原因，如果这样写

　　while((*s++=*t++))，就用括号表明了这是一个赋值语句而不是因为疏忽大意写的关系表达式，另外还有一些程序员喜欢把常量（或者说是右值放在==的左侧）比如：

　　　　if('\n'==x);

这样在编译时如果不小心写成了=也因为编译器的检查（不能赋值）而发现错误，在编译时刻犯错总比在运行时刻犯错要好！

　　总之在所有=和==可能混淆的语句中（尤其是if/while/for）如果开启了-Wall或者其它警告选项，GCC就会发出这样的警告，这个时候强烈建议你把GCC提示的地方检查一下！

　　第二个警告是 warning: control reaches end of non-void function （警告：控制流到达返回值非void的函数结尾）。这是因为我们定义了int main()，而结束时却没有使用return返回一个int产生的。在早期的K&R C中任何没有显式规定返回类型的函数都默认返回一个int值，任何没有显式返回的非void函数都会返回一个int值（实际上还有任何没有定义类型的变量都会被定义为int型变量，任何没有显式转换的malloc返回值都会被认为是char*……正是一些奇怪的定义），而在C++中，如果main函数结尾没有返回，则会自动加上return 0。这些也正是为什么GCC会通过这个函数的原因，在main()中返回数值的作用大家都是直到，不过如果这个警告出现在别的函数中就要注意了！

　　好的，下面是改进过后的程序：

　　test1.c

#include <stdio.h>
int main()
{
    char str_t[]="This String comes from t";//初始化字符数组
    char str_s[]="This is an empty string  ";//初始化字符数组
    char *t=str_t;//初始化字符指针
    char *s=str_s;//初始化字符指针
    while((*s++=*t++))//*的优先级比++高，且为右结合，因此会将t的值逐个赋值给s，直到结果为'\0'
        ;
    printf("%s\n%s\n",str_t,str_s);
    return 0;
}

　　重新用$gcc test1.c -Wall，发现没有刚才的警告了。

　　编译器的警告虽然不是错误，但是很多都是介与正确和错误之间的哪些部分，虽然编译器的警告不能使我们的程序百分之百正确，但会使我们离这个目标越来越近，重视编译器的警告也是一个好程序员的习惯。