Abraxas Software, Inc.

Voting System Standards - CodeCheck Rule-Files

VSS Package Index  Abraxas VSS Home Table of Contents

VSS Standards Test Suite - *.c

Abraxas Software, Inc.

Module - v422a.html

// 4.2.2 Software Integrity

/*

Self-modifying, dynamically loaded, or interpreted code is prohibited, except under

the security provisions outlined in section 6.4.e. This prohibition is to ensure that the

software tested and approved during the qualification process remains unchanged and

retains its integrity. External modification of code during execution shall be

prohibited. Where the development environment (programming language and

development tools) includes the following features, the software shall provide

controls to prevent accidental or deliberate attempts to replace executable code:

*/

// a Unbounded arrays or strings (includes buffers used to move data)

// global

char foo[];	// bad unbounded

char foo1[100];	// good

// local

Function Definition: v1
char foo[];	// bad unbounded
char foo1[100];	// good
Abraxas Software, Inc.
Module - v422b.html
// 4.2.2 Software Integrity
/*
Self-modifying, dynamically loaded, or interpreted code is prohibited, except under
the security provisions outlined in section 6.4.e. This prohibition is to ensure that the
software tested and approved during the qualification process remains unchanged and
retains its integrity. External modification of code during execution shall be
prohibited. Where the development environment (programming language and
development tools) includes the following features, the software shall provide
controls to prevent accidental or deliberate attempts to replace executable code:
*/
// b Pointer variables
cp = 1;		// NO, verboten
*cp = 1;	// NO
Function Definition: vss_542b
		cp = 1;		// NO, verboten
		*cp = 1;	// NO
Abraxas Software, Inc.
Module - v422c.html
// 4.2.2 Software Integrity
/*
Self-modifying, dynamically loaded, or interpreted code is prohibited, except under
the security provisions outlined in section 6.4.e. This prohibition is to ensure that the
software tested and approved during the qualification process remains unchanged and
retains its integrity. External modification of code during execution shall be
prohibited. Where the development environment (programming language and
development tools) includes the following features, the software shall provide
controls to prevent accidental or deliberate attempts to replace executable code:
*/
// c Dynamic memory allocation and management.
Function Definition: v422c
	char *mp = malloc(100);	// illegal
	free(mp);				// illegal
Abraxas Software, Inc.
Module - v423a.html
/*
423a. Each module shall have a specific function that can be tested and verified
independently of the remainder of the code. In practice, some additional
modules (such as library modules) may be needed to compile the module
under test, but the modular construction allows the supporting modules to be
replaced by special test versions that support test objectives;
1 Some software languages and development environments use a different definition of
module but this principle still applies.
*/
Function Definition: vss_v423a
Function Definition: vss_v423a
Abraxas Software, Inc.
Module - v423b.html
/*
VSS 423b. Each module shall be uniquely and mnemonically named, using names that
differ by more than a single character. In addition to the unique name, the
modules shall include a set of header comments identifying the module’s
purpose, design, conditions, and version history, followed by the operational
code. Headers are optional for modules of fewer than ten executable lines
where the subject module is embedded in a larger module that has a header
containing the header information. Library modules shall also have a header
comment describing the purpose of the library and version information;
*/
Function Definition: vss_423b
vss_423b() {	// good function, is similiar to module name
Function Definition: test
test() {	// ok, small routine
Function Definition: testfun
testfun() {	// bad this function doesn't belong here
Abraxas Software, Inc.
Module - v423c.html
/*
423c. All required resources, such as data accessed by the module, should either be
contained within the module or explicitly identified as input or output to the
module. Within the constraints of the programming language, such resources
shall be placed at the lowest level where shared access is needed. If that
shared access level is across multiple modules, the definitions should be
defined in a single file (called header files in some languages, such as C)
where any changes can be applied once and the change automatically applies
to all modules upon compilation or activation;
*/
int v423c ;	// no global data
Abraxas Software, Inc.
Module - v423e.html
/*
423e. Each module shall have a single entry point, and a single exit point, for
normal process flow. For library modules or languages such as the objectoriented
languages, the entry point is to the individual contained module or
method invoked. The single exit point is the point where control is returned.
At that point, the data that is expected as output must be appropriately set.
The exception for the exit point is where a problem is so severe that
execution cannot be resumed. In this case, the design must explicitly protect
all recorded votes and audit log information and must implement formal
exception handlers provided by the language; and
*/
Function Definition: Func1
	/* Do some stuff with dog and clog here	*/
} 	/* This is not allowed two return points	*/
//This also applies to exit() calls.
Function Definition: vss_423e
	return;		// explicit return at end of function is ok, 
Abraxas Software, Inc.
Module - v425c.html
/*
425 c. Names shall be unique within an application. Names shall differ by more than
a single character. All single-character names are forbidden except those for
variables used as loop indexes. In large systems where subsystems tend to be
developed independently, duplicate names may be used where the scope of
the name is unique within the application. Names should always be unique
where modules are shared; 
*/
int d = 0;  /* not allowed unless used in as a loop index	*/
Function Definition: v4
	for ( ;; i ) {} // ok
	i++;	// bad
	dog++;	// good
Function Definition: v4a
//For example: 
	switch(i){	//not allowed 
Abraxas Software, Inc.
Module - v427a.html
/*
427 a. All modules shall contain headers. For small modules of 10 lines or less, the
header may be limited to identification of unit and revision information. Other
header information should be included in the small unit headers if not clear from
the actual lines of code.
*/
/* =========================================================================*/
/**                                                                           
    FUNCTION:      VSS_BeginTasks()
    PURPOSE:       Initialize all tasks.
    PARAMETERS:
		none
    OUTPUT PARAMETERS:
       	Integer
    RETURN VALUE:
       	int = 0 for success or positive value for failure 
    USE OF GLOBALS:
    FILES REFERENCED:
 
    FUNCTIONS CALLED:
        read
    REVISIONS:
*/
Function Definition: VSS_BeginTasks
// line 5
// line 10
// bad case, no header
Function Definition: VSS_BeginTask_BAD
// line 5
// line 10
Function Definition: v5tiny
	// ok, small
Abraxas Software, Inc.
Module - v427b.html
/*
427 b. Descriptive comments shall be provided to identify objects and data types.
All variables shall have comments at the point of declaration clearly
explaining their use. Where multiple variables that share the same meaning
are required, the variables may share the same comment;
*/
// first foo is bad at line 9, no comment associated
int fuu; /* ok */
// good
int fubar;	//good
Function Definition: v6
v6() {	// next foo is bad, no comment
	int fubar;	//good
//O.K.  Does this one also take into account - YES
/* good */ 
Abraxas Software, Inc.
Module - v542k.html
/*
5.4.2 Assessment of Coding Conventions
K. Has no line of code exceeding 80 columns in width (including comments and
tab expansions) without justification;
*/
// bad long line
Abraxas Software, Inc.
Module - v542r.html
/*
5.4.2 Assessment of Coding Conventions
r. Has functions with fewer than six levels of indented scope, counted as
follows:
*/
Function Definition: function_v542K
//1
//2
//3
//4
//5
//code
Function Definition: function_v542K_bad
//1
//2
//3
//4
//5
	if (  f > 0 ) { exit(); }	// six, ILLEGAL
Abraxas Software, Inc.
Module - v542s.html
/*
vss 542s. Initializes every variable upon declaration where permitted
*/
// global
int foo = 1;	//good
int foam;		// bad
// local
Function Definition: v8
	int foo = 1;	// good
	int foam;		// bad
Abraxas Software, Inc.
Module - v542u.html
/*
vss542u. Has all constants other than 0 and 1 defined or enumerated, or shall have a
comment which clearly explains what each constant means in the context of
its use. Where “0” and “1” have multiple meanings in the code unit, even
they should be identified. Example: “0” may be used as FALSE, initializing
a counter to zero, or as a special flag in a non-binary category.
*/
// good cases
char my_array[FOURLETTERWORD];	//	is fine
int array[100];	// good, has comment
// BAD CASES FOLLOW ....
Abraxas Software, Inc.
Module - v542v.html
/*
542 v. Only contains the minimum implementation of the “a = b ? c : d” syntax.
Expansions such as “j=a?(b?c:d):e;” are prohibited.
*/
Function Definition: f542v
a = b ? c : d ;		// even the usage of this is questionable, the use of nested is illegal
VSS Package Index  Abraxas VSS Home Table of Contents
CodeCheck Copyright (c) 1988-2006 by Abraxas Software Inc. (R). All rights reserved.