C Checker Reference Manual

January 1998

5.1 Introduction

	int f ( int n )
	{
		if ( n ) {
			return ( 1 );
		} else {
			return ( 0 );
		}
		return ( 2 );
	}

	#pragma TenDRA unreachable code permit

There are also equivalent command-line options to tchk of the form -X:unreached=state, where state can be check, warn or dont.

Annotations to the code in the form of user-defined keywords may be used to indicate that a certain statement is genuinely reached or unreached. These keywords are introduced using:

	#pragma TenDRA keyword REACHED for set reachable
	#pragma TenDRA keyword UNREACHED for set unreachable

	int f ( int n ) {
		if ( n ) {
			return ( 1 );
	} else {
			return ( 0 )
		}
		REACHED
		return ( 2 );
	}

	int f ( int c ){
		if ( c ) return ( 1 );
		UNREACHED
	}

	#ifdef __TenDRA__
	#pragma TenDRA keyword REACHED for set reachable
	#pragma TenDRA keyword UNREACHED for set unreachable
	#else
	#define REACHED
	#define UNREACHED
	#endif

	void f ( int n )
	{
		switch ( n ) {
			case 1 : puts ( "one" );
			case 2 : puts ( "two" );
		}
	}

In the default mode, the TenDRA C checker ignores all such fall throughs. A check to detect fall through in case statements is controlled by:

	#pragma TenDRA fall into case permit

There are also equivalent command-line options to tcc of the form -X:fall_thru=state, where state can be check, warn or dont.

Deliberate case fall throughs can be indicated by means of a keyword, which has been introduced using:

	#pragma TenDRA keyword FALL_THROUGH for fall into case

	void f ( int n ){
		switch ( n ) {
			case 1 : puts ( "one" );
			FALL_THROUGH
			case 2 : puts ( "two" );
		}
	}

If a keyword is introduced in this way, then an alternative definition needs to be introduced for conventional compilers. This might be done as follows:

	#ifdef __TenDRA__
	#pragma TenDRA keyword FALL_THROUGH for fall into case
	#else
	#define FALL_THROUGH
	#endif

5.4 Unusual flow in conditional statements

	if( var1 == 1 ) ;
	var2 = 0 ;

	#pragma TenDRA extra ; after conditional permit

	#pragma TenDRA assignment as bool permit

	if( var = 1 ) { ...

	#pragma TenDRA const conditional permit

The precedence of operators is not always intuitive and often leads to unexpected results when expressions are evaluated. A particularly common example is to write:

	if ( var & TEST == 1) { ...
	}
	else { ...

	( ( var & TEST ) == 1 )

	( var & ( TEST == 1 ) )

.

The TenDRA C checker can be configured to flag expressions containing certain operators whose precedence is commonly confused, namely:

• && versus ||

• << and >> versus + and -

• & versus == != < > <= >= + and -

• ^ versus & == |= < > <= >= + and -

• | versus ^ & == |= < > <= >= + and -

	#pragma TenDRA operator precedence status

	#pragma TenDRA variable analysis status

There are also equivalent command line options to tchk of the form -X:variable=state, where state can be check, warn or dont.

The variable analysis is concerned with the evaluation of expressions and the use of local variables, including function arguments. Occasionally it may not be possible to statically perform a full analysis on an expression or variable and in these cases the messages produced indicate that there may be a problem. If a full analysis is possible a definite error or warning is produced. The individual checks are listed in sections 5.6.1 to 5.6.6 and section 5.7 describes the source annotations which can be used to fine-tune the variable analysis.

• after the arguments and function expression of a function call have been evaluated but before the call itself;

• after the first operand of a logical &&, or || operator;

• after the first operand of the conditional operator, ?:;

• after the first operand of the comma operator;

• at the end of any full expression (a full expression may take one of the following forms: an initialiser; the expression in an expression statement; the controlling expression in an if, while, do or switch statement; each of the three optional expressions of a for statement; or the optional expression of a return statement).

	var = i + arr[ i++ ] ;

	var = arr[i++] + i++ ;

	int f ( int n )
	{
		int r;
		return ( 0 );
	}

	int f ( int n )
	{
		int r = 1;
		r = 5;
		return ( r );
	}

	int f ( int n )
	{
		int r = 1;
		if ( n == 3 ) {
			r = 5;
		}
		return ( r );
	}

	int f ( int n )
	{
		int r = 1;
		if ( n == 3 ) {
			r = 5;
		} else {
			r = 6;
		}
		return ( r );
	}

	int f ( int n )
	{
		int r;
		if ( n == 3 ) {
			r = 5;
		}
		return ( r );
	}

	int f ( int n )
	{
		int r;
		if ( n == 3 ) {
			r = 5;
		} else {
			r = 6;
		}
		return ( r );
	}

	#pragma TenDRA discard x;

	if ( n == 3 )
	#pragma TenDRA discard x;
		puts ( "n is three" );

	#pragma TenDRA keyword DISCARD for discard variable

	DISCARD ( x );

	#ifdef __TenDRA__
	#pragma TenDRA keyword DISCARD for discard variable
	#else
	#define DISCARD(x) (( void ) 0 )
	#endif

	void f ( void ) {
		int i = 0;
		while ( i++ < 10 )
			{ puts ( "hello" ); }
		while ( i++ < 10 ) 
			{ puts ( "goodbye" ); }
	}

	void f ( int n )
	{
		int r;
		if ( n != 0 ) r = n;
		if ( n > 2 ) {
			printf ( "%d\n", r );
		}
	}

Programmers may assert that the variable, r, is set either by means of a pragma:

	#pragma TenDRA set r;

	SET ( r );

	#pragma TenDRA keyword SET for set

	char *f ( int n ){
		char *r;
		switch ( n ) {
			case 1:r="one";break;
			case 2:r="two";break;
			case 3:r="three";break;
		}
		return ( r );
	}

Programmers may assert that a switch statement is exhaustive by means of a pragma immediately following it. For example, in the above case it would take the form:

	....
	switch ( n )
	#pragma TenDRA exhaustive
		{
			case 1:r="one";break;
			....

	#pragma TenDRA keyword EXHAUSTIVE for exhaustive

	switch ( n ) EXHAUSTIVE {
		case 1:r="one";break;

	#ifdef __TenDRA__
	#pragma TenDRA keyword EXHAUSTIVE for exhaustive
	#else
	#define EXHAUSTIVE
	#endif

	extern void error (const char*);
	char *f ( int n ) {
		char *r;
		switch ( n ) {
			case 1:r="one";break;
			case 2:r="two";break;
			case 3:r="three";break;
			default:error("Illegal value");
		}
		return ( r );
	}

1. That the function does not return a value. This is the usual meaning of void.

2. That the function never returns, for example the library function, exit, uses void in this sense.

Therefore, we need to be able to declare the fact that a function never returns. This is done by introducing a new type to stand for the non-returning meaning of void (some compilers use volatile void for this purpose). This is done by means of the pragma:

	#pragma TenDRA type VOID for bottom

	extern VOID error (const char *);

	#ifdef __TenDRA__
	#pragma TenDRA type VOID for bottom
	#else
	typedef void VOID;
	#endif

	#include <stdlib.h>
	
	int f ( int n )
	{
		exit ( EXIT_FAILURE );
		return ( n );
	}

	#pragma TenDRA discard analysis status

In addition, each of the component tests may be switched on and off independently using pragmas of the form:

	#pragma TenDRA discard analysis (function return) status
	#pragma TenDRA discard analysis (value) status
	#pragma TenDRA discard analysis (static) status

Detailed descriptions of the individual checks follow in sections 5.8.1 - 5.8.3. Section 5.9 describes the facilities for fine-tuning the discard analysis.

	#include <stdio.h>
	int main ()
	{
		puts ( "hello" );
		return ( 0 );
	}

	int f ( int n ) {
		int r = 4 
		if ( n == 3 ) {
			r == 5;
		}
		return ( r );
	}

	( void ) puts ( "hello" );

	#pragma TenDRA keyword IGNORE for discard value

	IGNORE puts ( "hello" );

	#ifdef __TenDRA__
	#pragma TenDRA keyword IGNORE for discard value
	#else
	#define IGNORE ( void )
	#endif

	#pragma TenDRA suspend static x y z