不要小瞧编译器的warning(持续添加中)

WARNING1:

Problem with missing parentheses

Problem: I received the following message:

warning: suggest parentheses around && within ||.

Solution: This message is issued when the compiler detects a condition where the order of evaluation of logical operators might affect the calculation, but parentheses were not used to explicitly control the order of evaluation. Consider the following example:

if (a || b && c)

The logical AND operator (&&) has higher precedence than the logical OR operator (||) and is evaluated first by the compiler. Because parentheses were not used to explicitly control the order of evaluation in the example statement, the compiler issues a warning if the implicit order of precedence is not what was intended.

For the example statement, if the intention was to have the logical AND operator (&&) evaluated first, the statement should be explicitly coded as follows:

if (a || (b && c))

For the example statement, if the intention was to have the logical OR operator (||) evaluated first, the statement should be explicitly coded as follows:

if ((a || b) && c)

WARNING2:

Enumeration value not handled

Problem: I received the following warning:

warning: enumeration value <value> not handled in switch

Solution: This warning occurs if you have a switch statement based on an enumeration type. For example, you might have an enumerated type that has nine values, but your switch only tests three of those values:

switch (myenum)  {
      case val1:
            …do something…
             break;
      case val2:
            …do something…
             break;
      case val3:
            …do something…
             break;
}

The logic in the previous example might be correct and you might not want to test for the other values. To remove the warning, add an empty default statement to the switch to handle the other values.

switch (myenum)  {
      case val1:
            …do something…
             break;
      case val2:
            …do something…
             break;
      case val3:
            …do something…
             break;
      default:
             /* do nothing */
             break;
}

你每次写switch都添加"default:"了吗？你敢保证每个enum值都考虑到了吗？

WARNING3:
 Dereferencing type-punned pointer will break strict-aliasing rules
　在 gcc 2.x 下编译没有任何 warning 信息的代码换到 gcc 3.x 版本下之后出现了类似的 warning 。原因是 gcc 3 引入了 strict aliasing 架构，当编译时使用了 -fstrict-aliasing 参数（该参数在使用了 -O2 , -O3, -Os 优化参数的情况下默认生效），
而源代码中存在一些违反了 strict-aliasing 规则的地方的话，编译器就会对这部分代码提出 warning 。
　gcc 3 manual 对于 -fstrict-aliasing 参数的说明是：Allows the compiler to assume the strictest aliasing rules applicable to the language being compiled.  
For C (and C++), this activates optimizations based on the type of expressions.  In particular, an object of one type is assumed never to reside at the same address as an object of a different type,
 unless the types are almost the same.  For example, an "unsigned int" can alias an "int", but not a "void*" or a "double".  A character type may alias any other type.
　简而言之， 在该参数激活的情况下，编译器希望不同类型的对象不会指向同一个地址。比如像这段代码：
 
int retLen;
someSetFunc((unsigned long*)&retLen);
printf("ret len = %d/n",retLen);
 
    由于 someSetFunc 的传入参数类型定义为 unsigned long ，所以需要进行这样的指针类型强制 cast 。但对于 -fstrict-aliasing 优化参数来说，这样的转换是有潜在问题的（但实际上可能并不会造成任何问题）。
所以如果现有的源代码存在太多这样的类型强制转换的问题的话，对这些代码进行修改也许会是场噩梦。
最简单的方法是使用 -fno-strict-aliasing 参数来关闭 gcc 的优化选项，代价是放弃了 strict-aliasing 编译优化可能带来的可执行代码的性能提升。
当然也可以用 -Wno-strict-aliasing 来屏蔽相关的 warning 信息，但无论这些 warning 信息多么的无关紧要，总还是“疑似危险”，所以可能的话最好还是把所有的 warning 都消灭掉。
　消灭的方法也不算复杂，正如 gcc manual 所示的那样，可以是采用 union 的不同成员变量来完成类型的转换。上面那段代码可以改为：
 
union u_retLen
{
int retLen;
unsigned long ptr;
};
someSetFunc(&u_retLen.ptr);
printf("ret len = %d/n",u_retLen.retLen);
 
　　虽然会使源代码变得丑陋，但对于大部分已有的源代码来说，这可能是改动最小的方案了。而对于新写的代码来说，如何更好的设计函数的入口参数（比如使用 void*）可能才是需要去思考的问题了。