Porting to ANSI Mode HP C

A common pitfall when mixing prototypes with old-style function definitions is to overlook the ANSI rule that for parameter types to be compatible, the parameter type in the prototype must match the parameter type resulting from default promotions applied to the parameter in the old-style function definition.

For example:

void func1(char c);
void func1(c)
char c;
{ }

gets the following message when compiled in ANSI mode:

Inconsistent parameter list declaration for "func1"

The parameter type for c in the prototype is char. The parameter type for c in the definition func1 is also char, but it expects an int because it is an old-style function definition and in the absence of a prototype, char is promoted to int.

Changing the prototype to:

void func1(int c);

fixes the error.

The ANSI C standard does not require a compiler to do any parameter type checking if prototypes are not used. Value parameters whose sizes are larger than 64 bits (8 bytes) will be passed via a short pointer to the high-order byte of the parameter value. The receiving function then makes a copy of the parameter pointed to by this short pointer in its own local memory.

There are three things to consider when using function prototypes:

When a prototype to a function is added, be careful that all calls to that function occur with the prototype visible (in the same context). The following example illustrates problems that can arise when this is not the case:

func1(){
  float f;
  func2(f);
}
 
int func2(float arg1){
    /* body of func2 */
}

In the example above, when the call to func2 occurs, the compiler behaves as if func2 had been declared with an old-style declaration int func2(). For an old-style call, the default argument promotion rules cause the parameter f to be converted to double. When the declaration of func2 is seen, there is a conflict. The prototype indicates that the parameter arg1 should not be converted to double, but the call in the absence of the prototype indicates that arg1 should be widened. When this conflict occurs within a single file, the compiler issues an error:

Inconsistent parameter list declaration for "func2".

This error can be fixed by either making the prototype visible before the call, or by changing the formal parameter declaration of arg1 to double. If the declaration and call of func2 were in separate files, then the compiler would not detect the mismatch and the program would silently behave incorrectly.

On HP-UX, the lint(1) command can be used to find such parameter inconsistencies across files.

Another potential prototype problem occurs when structures are declared within a prototype parameter list. The following example illustrates a problem that may arise:

func3(struct stname *arg);
struct stname { int i; };
 
void func4(void) {
   struct stname s;
   func3(&s);
}

In this example, the call and declaration of func3 are not compatible because they refer to different structures, both named stname. The stname referred by the declaration was created within prototype scope. This means it goes out of scope at the end of the declaration of func3. The declaration of stname on the line following func3 is a new instance of struct stname. When conflicting structures are detected, the compiler issues an error:

types in call and definition of 'func3' have incompatible
struct/union pointer types for parameter 'arg'

This error can be fixed by switching the first two lines and thus declaring struct stname prior to referencing it in the declaration of func3.

Mixing the const and volatile qualifiers and prototypes can be tricky. Note that this section uses the const qualifier for all of its examples; however, you could just as easily substitute the volatile qualifier for const. The rules for prototype parameter passing are the same as the rules for assignments. To illustrate this point, consider the following declarations:

/* pointer to pointer to int */
int **actual0;

Figure 5-1 Title not available (Mixing of const and volatile Qualifiers and Function Prototypes )

/* const pointer to pointer to int */
int **const actual1;

Figure 5-2 Title not available (Mixing of const and volatile Qualifiers and Function Prototypes )

/* const pointer to const pointer to int */
int *const *const actual2;

Figure 5-3 Title not available (Mixing of const and volatile Qualifiers and Function Prototypes )

/* const pointer to const pointer to const int */
const int *const *const actual3;

Figure 5-4 Title not available (Mixing of const and volatile Qualifiers and Function Prototypes )

These declarations show how successive levels of a type may be qualified. The declaration for actual0 has no qualifiers. The declaration of actual1 has only the top level qualified. The declarations of actual2 and actual3 have two and three levels qualified. When these actual parameters are substituted into calls to the following functions:

void f0(int **formal0);
void f1(int **const formal1);
void f2(int *const *const formal2);
void f3(const int *const *const formal3);

The compatibility rules for pointer qualifiers are different for all three levels. At the first level, the qualifiers on pointers are ignored. At the second level, the qualifiers of the formal parameter must be a superset of those in the actual parameter. At levels three or greater the parameters must match exactly. Substituting actual0 through actual3 into f0 through f3 results in the following compatibility matrix: