When a function is called, the prototype of the called function must be declared. If a function is called without a prototype declaration, parameters may not be received and passed correctly.
The function has signed char, (unsigned) char, (signed) short, and unsigned short type parameters passed by stack. |
void h(); void g() { char a,b; ... h(1,2,3,4,a,b); // Converts a and b to int type } void h(int a1, int a2, int a3, int a4, char a5, char a6) {...} |
When more than one function declaration (including function definition) is made for the same function, do not use both a format in which parameters and types are not specified together and a format in which parameters and types are specified together.
If both formats are used, the generated code may not process types correctly because there is a difference in how the parameters are interpreted in the caller and callee.
When the error message C5147 is displayed at compilation, this problem may have caused it. In such a case, either use only a format in which parameters and types are specified together or check the generated code to ensure that there is no problem in parameter passing.
Since old_style is written in different formats, the meaning of the types of parameters d and e are different in the caller and callee. Thus, parameters are not passed correctly. |
When using an expression whose evaluation order is not specified in the C/C++ language specifications, the operation is not guaranteed in a program code whose execution results differ depending on the evaluation order.
Even if an overflow operation or floating-point zero division is performed, error messages will not be output. However, if an overflow operation is included in the operations of a single constant or between constants, error messages will be output at compilation.
Even if a variable is declared with const type, if assignment is done to a non-const type variable converted from const type or if a program compiled separately uses a parameter of a different type, the compiler cannot check the writing to a const type variable. Therefore, precautions must be taken.
For functions acos(x) and asin(x), an error is large around x=1. Therefore, precautions must be taken. The error range is as follows:
Absolute error for acos(1.0 − ε) double precision 2-39 (ε = 2-33)
single precision 2-21 (ε = 2-19)
Absolute error for asin(1.0 − ε) double precision 2-39 (ε = 2-28)
single precision 2-21 (ε = 2-16)
A code continuously referencing the same variable or a code containing an expression whose result is not used may be deleted as redundant codes at optimization by the compiler. Variables should be declared with volatile in order for accesses to always be guaranteed.
In the C99, selection statements and repeat statements are enclosed in curly brackets { }. This causes operations to differ in the C89 and C99.
If the above code is compiled with -lang=c99 specified, it is interpreted as follows:
g()=0 in -lang=c becomes g()=1 in -lang=c99.
The result of any operation or type conversion must be within the allowed range of values for the given type (i.e. values must not overflow). If an overflow does occur, the result of the operation or type conversion may be affected by other conditions such as compiler options.
In the standard C language, the result of an operation that leads to an overflow is undefined and thus may differ according to the current conditions of compilation. Ensure that no operations in a program will lead to an overflow.
The following example illustrates this problem.
float f = 2147483648.0f; unsigned short ui2; void ex1func(void) { ui2 = f; /* Type conversion from float to unsigned short */ } |
The value of ui2, which is acquired as the result of executing ex1func, depends on whether –fpu or –nofpu has been specified.
-fpu (with the FPU): ui2 = 65535
-nofpu (without the FPU): ui2 = 0
This is because the method of type conversion from float to unsigned short differs according to whether –fpu or –nofpu has been specified.
Symbols must not contain sequences of two or more underscores. Even though the code generated in such cases seems normal, the symbol names may be mistaken as different C++ function names when they are output as linkage-map information.
This will be output to the linkage map as sample(char) rather than _sample__Fc.