In this section:

Overview

This error is generated when an argument to a function or subroutine does not match the type specified in an earlier declaration or an interface file. Insure++ distinguishes several types of mismatches which have different levels of severity as follows:

Code	Description	Reported	Platform
BAD_PARM	Mismatch in argument type.	Compilation	Windows/Unix
(sign)	Types differ only by sign, e.g., `int` vs. `unsigned int`	Compilation	Windows/Unix
(compatible)	Fundamental types are different but they happen to have the same representation on the particular hardware in use, e.g., `int` vs. `long` on machines where both are 32-bits.	Compilation	Windows/Unix
(incompatible)	Fundamental types are different, e.g., `int` vs. `double`	Compilation	Windows/Unix
(pointer)	This is not an error class, but a keyword used to suppress messages about mismatched pointer types, such as `int ` vs. `char `.	Compilation	Windows/Unix
(union)	Forces a declared union argument to match only a similar union as an actual argument. If this is suppressed, you may pass any of the individual union elements to the routine, rather than the union type, or pass a union to a routine which expects one of the union-elements as an argument.	Compilation	Windows/Unix
(other)	A problem other than an argument type mismatch is detected, such as passing the wrong number of arguments. Error messages are classified according to this scheme and can be selectively enabled or disabled	Compilation	Windows/Unix

Error messages are classified according to this scheme and can be selectively enabled or disabled as described in Repair.

Problem 1

The following shows an error in which an incorrect argument is passed to the function foo.

/*
 * File: badparm1.c
 */
void foo(str)
	char *str;
	{
		return;
	}

main()
	{
		int *iptr;

		foo(iptr);
		return (0);
	}

This type of mismatch is detected during compilation.

Diagnosis During Compilation

[badparm1.c:14] **BAD_PARM(incompatible)**
		Wrong type passed to foo (argument 1: str)
		Expected char *, found int *.
>> 				foo(iptr)

Line 1: Source line at which the problem was detected.
Line 2: Description of the problem and the arguments that are incorrect.

Problem 2

Another simple problem occurs when arguments are passed to functions in the wrong order, as in the following example.

/*
 * File: badparm2.c
 */
long foo(f, l)
	double f;
	long l;
{
	return f+l;
}

main()
{
	long ret = foo(32L, 32.0);

	printf("%ld\n", ret);
	return 0;
}

Diagnosis During Compilation

[badparm2.c:13] **BAD_PARM(incompatible)**2
		Wrong type passed to foo (argument 1: f)
		Expected double, found long.
>> 				long ret = foo(32L, 32.0);

[badparm2.c:13] **BAD_PARM(incompatible)**
		Wrong type passed to foo (argument 2: l).
		Expected long, found double.
>> 				long ret = foo(32L, 32.0);

Line 1: Source line at which the problem was detected.
Line 2: Description of the problem and the arguments that are incorrect.

Problem 3

The following example illustrates the BAD_PARM(union) error category. The func1 and func2 functions expect to be passed a union and a pointer to an integer, respectively. The code in the main routine then invokes the two functions both properly and by passing the incorrect types.

This code will probably work on most systems due to the internal alignment of the various data types. Relying on this behavior is, however, non-portable.

/*
 * File: badparm4.c
 */
union data {
	int i;
	double d;
};

void func1(ptr)
	union data *ptr;
{
	ptr->i = 1;
}

void func2(p)
	int *p;
{
	*p = 1;
}

main()
{
	int t;
	union data u;

	func1(&u);
	func1(&t); 		/* BAD_PARM */
	func2(&u); 		/* BAD_PARM */
	func2(&t);
}

Diagnosis at Compilation

[badparm4.c:27] **BAD_PARM(union)**
	Wrong type passed to func1 (argument 1: ptr)
	Expected union data *, found int *.
>> 		func1(&t);	 /* BAD_PARM */
[badparm4.c:28] **BAD_PARM(union)**
	Wrong type passed to func2 (argument 1: p)
	Expected int *, found union data *.
>> 		func2(&u);	 /* BAD_PARM */

Line 1: Source line at which the problem was detected.
Line 2: Description of the problem and the arguments that are incorrect.

Repair

Most of these problems are simple to correct based on the information provided. For example, you can change the code in #Problem 1 so that the pointer types (char, int) match. The other problems can be similarly corrected.

If your application generates error messages that you wish to ignore, you can suppress BAD_PARM.

This directive suppresses all BAD_PARM messages. If you wish to be more selective and suppress only a certain type of error, you can use the following syntax where the arguments are one or more of the identifiers for the various categories of error described in the Overview:

BAD_PARM(class1, class2, …)

Similarly, you can enable suppressed error messages to enable warnings about conflicts between types int and long on systems where they are the same number of bytes by unsuppressing BAD_PARM(compatible).

In addition to the keywords described in the Overview, you can also use the pointer type to suppress all messages about different pointer types.

For example, many programs declare functions with the argument type char *, which are then called with pointers to various other data types. The ANSI standard recommends that you use type void * in such circumstances, since this is allowed to match any pointer type. If, for some reason, you cannot do this, you can suppress messages from Insure++ about incompatible pointer types by suppressing in the Suppressions Control Panel.