user’s guide - massachusetts institute of technology · pdf fileiii parasoft end user...

User’s GuideVersion 4.3

UNIX

i

Parasoft Corporation101 E. Huntington Drive, 2nd Floor

Monrovia, CA 91016Phone: (888) 305-0041

Fax: (626) 256-6884E-mail: [email protected]

URL: www.parasoft.com

Copyright© 1993-2004

Printed in the U.S.A January 15, 2004

ii

PARASOFT END USER LICENSE AGREEMENTREDISTRIBUTION NOT PERMITTEDThis Agreement has 3 parts. Part I applies if you have not purchased a license to the accompanying software (the "SOFTWARE"). Part II applies if you have purchased a license to the SOFTWARE. Part III applies to all license grants. If you initially acquired a copy of the SOFTWARE without purchasing a license and you wish to purchase a license, contact ParaSoft Corporation ("PARASOFT"):

(626) 305-0041

(888) 305-0041 (USA only)

(626) 305-9048 (Fax)

[email protected]

http://www.parasoft.com

PART I -- TERMS APPLICABLE WHEN LICENSE FEES NOT (YET) PAID GRANT.DISCLAIMER OF WARRANTY. Free of charge SOFTWARE is provided on an "AS IS" basis, without warranty of any kind, including without limita-tion the warranties of merchantability, fitness for a particular purpose and non-infringement. The entire risk as to the quality and performance of the SOFTWARE is borne by you. Should the SOFTWARE prove defective, you and not PARASOFT assume the entire cost of any service and repair. This disclaimer of warranty constitutes an essential part of the agreement. SOME JURISDICTIONS DO NOT ALLOW EXCLUSIONS OF AN IMPLIED WARRANTY, SO THIS DISCLAIMER MAY NOT APPLY TO YOU AND YOU MAY HAVE OTHER LEGAL RIGHTS THAT VARY BY JURISDICTION.

PART II -- TERMS APPLICABLE WHEN LICENSE FEES PAIDGRANT OF LICENSE. PARASOFT hereby grants you, and you accept, a limited license to use the enclosed electronic media, user man-uals, and any related materials (collectively called the SOFTWARE in this AGREEMENT). You may install the SOFTWARE in only one location on a single disk or in one location on the temporary or permanent replacement of this disk. If you wish to install the SOFTWARE in multiple locations, you must either license an additional copy of the SOFTWARE from PARASOFT or request a multi-user license from PARASOFT. You may not transfer or sub-license, either temporarily or permanently, your right to use the SOFTWARE under this AGREEMENT without the prior written consent of PARASOFT.

LIMITED WARRANTY. PARASOFT warrants for a period of thirty (30) days from the date of purchase, that under normal use, the material of the electronic media will not prove defective. If, during the thirty (30) day period, the software media shall prove defective, you may return them to PARASOFT for a replacement without charge.

THIS IS A LIMITED WARRANTY AND IT IS THE ONLY WARRANTYMADE BY PARASOFT. PARASOFT MAKES NO OTHER EXPRESS WARRANTY AND NO WARRANTY OF NONINFRINGEMENT OF THIRD PARTIES' RIGHTS. THE DURATION OF IMPLIED WARRANTIES, INCLUDING WITHOUT LIMITATION, WARRANTIES OF MERCHANTABILITY AND OF FITNESS FOR A PARTICULAR PURPOSE, IS LIMITED TO THE ABOVE LIMITED WARRANTY PERIOD; SOME JURISDICTIONS DO NOT ALLOW LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY LASTS, SO LIMITATIONS MAY NOT APPLY TO YOU. NO PARASOFT DEALER, AGENT, OR EMPLOYEE IS AUTHORIZED TO MAKE ANY MODIFICATIONS, EXTENSIONS, OR ADDITIONS TO THIS WARRANTY.

iii

If any modifications are made to the SOFTWARE by you during the warranty period; if the media is subjected to accident, abuse, or improper use; or if you violate the terms of this Agreement, then this warranty shall immedi-ately be terminated. This warranty shall not apply if the SOFTWARE is used on or in conjunction with hardware or software other than the unmodified version of hardware and software with which the SOFTWARE was designed to be used as described in the Documentation. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS, AND YOU MAY HAVE OTHER LEGAL RIGHTS THAT VARY BY JURISDICTION.

YOUR ORIGINAL ELECTRONIC MEDIA/ARCHIVAL COPIES. The electronic media enclosed contain an original PARASOFT label. Use the original electronic media to make "back-up" or "archival" copies for the purpose of running the SOFTWARE program. You should not use the original electronic media in your terminal except to create the archival copy. After recording the archival copies, place the original electronic media in a safe place. Other than these archival copies, you agree that no other copies of the SOFTWARE will be made.

TERM. This AGREEMENT is effective from the day you install the SOFTWARE and continues until you return the original SOFTWARE to PARASOFT, in which case you must also certify in writing that you have destroyed any archival copies you may have recorded on any memory system or magnetic, electronic, or optical media and likewise any copies of the written materials.

CUSTOMER REGISTRATION. PARASOFT may from time to time revise or update the SOFTWARE. These revisions will be made generally avail-able at PARASOFT's discretion. Revisions or notification of revisions can only be provided to you if you have reg-istered with a PARASOFT representative or on the ParaSoft Web site. PARASOFT's customer services are available only to registered users.

PART III -- TERMS APPLICABLE TO ALL LICENSE GRANTSSCOPE OF GRANT.DERIVED PRODUCTS. Products developed from the use of the SOFTWARE remain your property. No royalty fees or runtime licenses are required on said products.

PARASOFT'S RIGHTS. You acknowledge that the SOFTWARE is the sole and exclusive property of PARASOFT. By accepting this agree-ment you do not become the owner of the SOFTWARE, but you do have the right to use the SOFTWARE in accor-dance with this AGREEMENT. You agree to use your best efforts and all reasonable steps to protect the SOFTWARE from use, reproduction, or distribution, except as authorized by this AGREEMENT. You agree not to disassemble, de-compile or otherwise reverse engineer the SOFTWARE.

SUITABILITY. PARASOFT has worked hard to make this a quality product, however PARASOFT makes no warranties as to the suitability, accuracy, or operational characteristics of this SOFTWARE. The SOFTWARE is sold on an "as-is" basis.

EXCLUSIONS. PARASOFT shall have no obligation to support SOFTWARE that is not the then current release.

TERMINATION OF AGREEMENT. If any of the terms and conditions of this AGREEMENT are broken, this AGREEMENT will terminate automatically. Upon termination, you must return the software to PARASOFT or destroy all copies of the SOFTWARE and Docu-mentation. At that time you must also certify, in writing, that you have not retained any copies of the SOFTWARE.

iv

LIMITATION OF LIABILITY. You agree that PARASOFT's liability for any damages to you or to any other party shall not exceed the license fee paid for the SOFTWARE.

PARASOFT WILL NOT BE RESPONSIBLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM THE USE OF THE SOFTWARE ARISING OUT OF ANY BREACH OF THE WARRANTY, EVEN IF PARASOFT HAS BEEN ADVISED OF SUCH DAMAGES. THIS PRODUCT IS SOLD "AS-IS".

SOME STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CON-SEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT APPLY TO YOU. YOU MAY ALSO HAVE OTHER RIGHTS WHICH VARY FROM STATE TO STATE.

ENTIRE AGREEMENT.This Agreement represents the complete agreement concerning this license and may be amended only by a writ-ing executed by both parties. THE ACCEPTANCE OF ANY PURCHASE ORDER PLACED BY YOU IS EXPRESSLY MADE CONDITIONAL ON YOUR ASSENT TO THE TERMS SET FORTH HEREIN, AND NOT THOSE IN YOUR PURCHASE ORDER. If any provision of this Agreement is held to be unenforceable, such pro-vision shall be reformed only to the extent necessary to make it enforceable. This Agreement shall be governed by California law (except for conflict of law provisions).

All brand and product names are trademarks or registered trademarks of their respective holders.

Copyright 1993-2004

Parasoft Corporation

101 E. Huntington Drive, 2nd Floor

Monrovia, CA 91016Printed in the U.S.A, January 15, 2004

v

CodeWizard User’s Guide

IntroductionIntroduction ..................................................................................................................................................1Installation....................................................................................................................................................3

Using CodeWizardUsing CodeWizard.......................................................................................................................................10Preventing Errors in Embedded Development.............................................................................................13

Customizing CodeWizardCreating Custom Coding Standards ............................................................................................................17Customizing Output With Suppressions ......................................................................................................19

Static Analysis RulesGlobal Reporting System.............................................................................................................................28Oracle Proc Files .........................................................................................................................................29Customizing CodeWizard Options With Configuration Files........................................................................30

Viewing Results in InsraInsra.............................................................................................................................................................42

Static Analysis RulesRules Enforced ............................................................................................................................................48

Effective C++ ItemsEffective C++ Items .....................................................................................................................................49

More Effective C++ ItemsMore Effective C++ Items ............................................................................................................................80

Built-in MISRA ItemsBuilt-in MISRA Guidelines ...........................................................................................................................89

vi

Meyers-Klaus ItemsMeyers-Klaus Items .....................................................................................................................................130

Universal Coding Standard ItemsUniversal Coding Standard Items ................................................................................................................133

User ItemsUser Items ...................................................................................................................................................169

Ellemtel (Telecom Industry) ItemsEllemtel (Telecom Industry) Items ...............................................................................................................269

MISRA GuidelinesUser MISRA Guidelines...............................................................................................................................344

Legal NoticesLegal Notices ...............................................................................................................................................442

IndexIndex ............................................................................................................................................................451

vii

Introduction

IntroductionIntroductionWelcome to CodeWizard, a unique C/C++ tool that prevents errors by automatically enforcing built-inand custom C/C++ coding standards.

Coding standards are language-specific rules that, if followed, will significantly reduce the opportunityfor you to make errors. When you consistently implement and enforce coding standards for everyproject, you can prevent errors from entering code and greatly reduce the amount of debugging thatyou must perform to find and fix errors after they have been introduced.

CodeWizard automatically enforces C and C++ coding standards to help you prevent errors and makeyour code more portable and maintainable. CodeWizard is an automatic source code analysis toolbased on programming ideas from C and C++ experts. CodeWizard enforces over 300 built-in C/C++coding standards, and any number of custom C/C++ coding standards that you create with RuleWiz-ard, a CodeWizard feature which lets you graphically create your own coding standards or customizeexisting CodeWizard coding standards. See “Rules Enforced” on page 48 for more information on thecoding standards enforced by CodeWizard.

If you develop software for embedded systems, CodeWizard can help you prevent errors before yourcode leaves the host system. CodeWizard enforces a set of coding standards designed specifically toprevent errors in embedded software development; it also lets you easily create and enforce your ownembedded development coding standards.

New Features for CodeWizard 4.3CodeWizard 4.3 for UNIX contains significant changes from previous versions that will help youprevent coding errors more efficiently. New features/enhancements include:

• Support for Global Reporting System (GRS). This provides a single place to store reports fromCodeWizard processes running on multiple machines (for example, during nightly builds).

• Support for Python scripting and cross-rules in the enhanced RuleWizard functionality.

• Support for new #pragma codewizard directive for fine-grained suppression control withinsource code.

• Support for two new rulesets based on MISRA and Telecom Industry coding standards.

• Support for "volatile" modifier in C++ dictionary of RuleWizard.

• Support for GCC 3.2.

• Added ability to return non-zero exit code if number of violations exceeds specified thresholds.This feature is particularly useful when using CodeWizard in scripts and nightly builds.

• General user enhancements.

1

Introduction

Supported Platforms and CompilersThe platforms and compilers supported by CodeWizard at the time this manual was printed are sum-marized in the table below:

The OS version listed is the version under which CodeWizard was built. Older OS versions may work, and newer versions will generally work. If you have a different compiler, you may be able to customize CodeWizard for your needs. For more information, contact technical support.

Platform OS VersionC++ Compilers C Compilers

CC cxx g++ xlC aCC gcc cc

AIX4 4.3.3 X X X X

AIX5L 5.1 X X X X

HP-UX 11 (IA-64)

11i v1.5 X X X X

HP-UX 11 (PA-RISC)

11.x, 11i X X X X

IRIX 6.5.x X X X X

Linux RedHat 6.2 - 7.3 (glibc 2.1-2.2) X X

Linux_PPC Yellow Dog 2.0+ (glibc 2.1+) X X

Solaris 7, 8, 9 X X X X

2

http://www.parasoft.com/jsp/products/support.jsp

Installation

InstallationThe following steps describe the process of installing CodeWizard from either:

• A physical medium such as a CD-ROM.

• An electronic archive obtained via our Web server.

Installing CodeWizard from a Web server requires no particular system privileges other than the abilityto create a directory into which the software will be placed. Installing from a CD-ROM requires rootprivileges.

Installing CodeWizard involves the following steps:

• Step 1. Create a Directory for Extracting the CodeWizard Distribution

• Step 2. Extract the CD-ROM Contents

• Step 3. Extract the Installation Script

• Step 4. Install CodeWizard

• Step 5. Install a License

• Step 6. Set the PARASOFT Environment Variable (Optional)

• Step 7. Modify your PATH Environment Variable

• Step 8: Redefine the LD_LIBRARY_PATH Variable

• Step 9: Set the JAVA_HOME Environment Variable (Optional)

• Step 10. Modify Your Environment

Each of these steps is fully explained in this section.

Step 1. Create a Directory for Extracting the CodeWizard DistributionChoose a location in which to install CodeWizard and make this directory with a command such as:mkdir /usr/local/parasoft

All subsequent steps must be performed in the new directory, so you should cd into that directory now:cd /usr/local/parasoft

Note: From now on we will assume that you have chosen to install software in a directory called/usr/local/parasoft as indicated above. If you actually choose a different directory name, youwill have to modify the following commands appropriately.

If you received CodeWizard on a CD-ROM, proceed to Step 2. Extract the CD-ROM Contents.If youreceived CodeWizard via our Web server, skip Step 2 and proceed directly to Step 3. Extract the Instal-lation Script.

3

Installation

Step 2. Extract the CD-ROM ContentsTo mount the CD-ROM, you must be at the root: su root

Create a /cdrom directory, if necessary: mkdir /cdrom.

The actual mount command is different on each platform we support. Please use the appropriate com-mand for your system. Note that the following commands assume that your CD-ROM drive is SCSI ID6. If your drive is at a different SCSI location, substitute the appropriate device file name for yourCD-ROM drive.

cd into the installation directory you created in Step 1: cd /usr/local/parasoft

Then copy the tar file for your platform to the current directory with the following command: cp /cdrom/wizard/tar/cARCH.tar

Unmount the CD-ROM with the following command: unmount /cdrom

Be sure to eject the CD-ROM from your CD drive before proceeding to Step 3.

Step 3. Extract the Installation ScriptExtract the installation script for a compressed file with the following command:

uncompress -c <name_of_tar_file> | tar xvf - install

or, for a zipped file:

gzip -dc <name_of_tar_file> | tar xvf - install

For the zipped file, the name of the tar file supplied to you should be inserted in place of the text<archive_file>. If you are installing from a CD-ROM and your tar file is not compressed, use the follow-ing command to extract the installation script:

tar xvf <name_of_tar_file> install

You are now ready to install CodeWizard on your system using the provided installation script. Steps 4through 9 will lead you through this procedure.

Platform Mount Command

IBM AIX mount -v cdrfs -r /dev/cd0 /cdrom

HP-UX mount -F cdfs -r /dev/disk/c0t6d0 /cdrom

Linux mount -t iso9660 -o ro /dev/scd0 /cdrom

SGI IRIX mount -t iso 9660 -r /dev/scsi/sc0d610 /cdrom

Solaris mount -F hsfs -r /dev/dsk/c0t6d0s2 /cdrom

4

Installation

Step 4. Install CodeWizardCodeWizard includes an installation script which will help you install CodeWizard on your system.

To run the installation script, execute the command: ./install

The script first prints version and Quality Consulting information:

Extracting installation script...

CodeWizard Installation Script

Copyright (C) 2003 by Parasoft Corporation

Quality Consulting is available at:

E-mail: [email protected]

Web: http://www.parasoft.com

Telephone: (626) 305-0041

Fax: (626) 305-9048

The script then asks you to confirm that you want to install CodeWizard into the current directory.

The CodeWizard distribution consists of the following directories and files.

• bin.$ARCH/: CodeWizard executables

• lib.$ARCH/: CodeWizard configuration files

• rules: CodeWizard built-in rules

• examples: CodeWizard example programs

• insra: Insra help files

• install: CodeWizard installation script

• manuals: CodeWizard User’s Guide files

• README: CodeWizard README

• release_notes.txt: CodeWizard release notes

Once the files have been installed, you will be led through a series of questions as the installation scriptconfigures CodeWizard for your system.

We recommend that you choose “yes” when asked if you want to use the default CodeWizard installa-tion. If you do, CodeWizard will be configured automatically. The script will update CodeWizard’s con-figuration files for use with your compilers.

This step does not tell CodeWizard which compiler to use when checking your source code. You willstill need to add the following option to your $HOME/.psrc file (if it doesn't exist, please create one):

codewizard.compiler CC

Note: CC can also be xlC, g++, cxx, aCC or whatever compiler is available on your system.

Once CodeWizard is installed, your system must be configured and a license installed before use. Youwill need to complete steps 5, 7, 8, and 10 before you can use CodeWizard.

5

Installation

Step 5. Install a LicenseAfter installing the necessary files, the installation script will ask if you would like to install a license touse CodeWizard.

Machine-Locked LicensesIf you need to install a machine-locked license, choose “Yes.” The script will start pslic, the ParasoftLicense Manager.

Note: If you get an error message from pslic saying that it cannot open a .psrc file, you shouldmake sure that you have write permission in the /usr/local/parasoft (installation) directoryand/or run pslic as superuser. pslic will print out your machine and network ID numbers. Youshould then phone, fax, or email this information to Parasoft. You will receive a license which you canenter using pslic.

Once you have the license, run pslic.

Choose the A option to add a license: (A)dd a license. The first item you will need to enter is thenetwork or host ID number, which should be the same number printed by pslic. Next, you will beprompted to enter the expiration date, which you received from Parasoft. Finally, enter the passwordyou were given. To complete the license installation, select E: (E)xit and save changes

Shared Network LicensesIf you are using Parasoft’s LicenseServer to manage a floating license, enter the following parametersin your .psrc file:

• LicenseServer_host ”hostname” (Replace “hostname” with the name of the machinehosting LicenseServer; for example, LicenseServer_host machine1).

• LicenseServer_port “port number” (Replace “port number” with the port that Licens-eServer is using; for example, LicenseServer_port 2002).

Note: You must first enter codewizard.networklicense yes in your .psrc file to activate the net-work license feature. The default setting is no.

Tip! If CodeWizard has problems obtaining a server license due to high network load, use the followingoptional parameter to increase the timeout period:

LicenseServer_timeout "timeout" (Replace "timeout" by license server timeout in seconds.

CodeWizard obtains the network license from the license server; connection data to the license serveris in the .psrc file, along with information concerning the local license. For example, in your .psrc fileyou can specify:

>>>> .psrc >>>># local licenseCodeWizard.Password 4.2 <machine ID> <password>

# network licenseCodeWizard.LicenseServer_host <host name>CodeWizard.LicenseServer_port 2222CodeWizard.networklicense yes<<<< .psrc <<<<

Using these settings, CodeWizard will obtain a local license, a valid CodeWizard.password, and allnecessary Network license server connection parameters, including license server port and host data(these are needed to get a license from the license server). Because the network license option is set

6

Installation

to yes, CodeWizard will use the network license. If this option were set to no, CodeWizard wouldchoose the local license.

Important: If you are using LicenseServer, you do not need to run pslic or enter anything in pslic.For information about the .psrc file, see “Customizing CodeWizard Options With Configuration Files”on page 30.

Step 6. Set the PARASOFT Environment Variable (Optional)This step is optional.

In most cases, you will not need to set this environment variable. However, you may find it useful as ashortcut to the CodeWizard installation. Also, a tool may prompt you to set this environment variable.

To set the PARASOFT environment variable correctly, you will need to know the name of the directoryin which CodeWizard has been installed on your system. Once you know this path you should defineand environment variable called PARASOFT to be this pathname.

Typically, you do this by editing the file .cshrc in your home directory and adding a line like one of thefollowing:

• For csh or tcsh shells: setenv PARASOFT /usr/local/parasoft

• For sh, ksh, or bash shells: PARASOFT=/usr/local/parasoft export PARASOFT

Step 7. Modify your PATH Environment VariableYou must add the directory containing the executables to your execution path. Normally, you do this byadding to the definition of either the path or PATH variables as follows:

• For csh and tcsh shells: set path=($path /usr/local/parasoft/bin.$ARCH)

• For sh, ksh, or bash shells: PATH=$PATH:/usr/local/parasoft/bin.$ARCH exportPATH

Important: Replace ARCH with the name of your architecture (aix4, alpha5, hp11, hp11_ia64, linux2,linux_ppc, sgi6, solaris).

The directory in which the executables are located will have a name which can be derived from thetype of system you are running on, and is given to you by the install script.

Many systems have a built-in command called ARCH which can be used to determine the name of thedirectory to put on your path as follows

• For csh or tcsh shells: set path= $path /usr/local/parasoft/bin.$ARCH)

• For sh, ksh, and bash shells: PATH=$PATH:/usr/local/parasoft/bin.$ARCH exportPATH

If you are not certain which directory to put on your search path, ask your system administrator for help.

7

Installation

Step 8: Redefine the LD_LIBRARY_PATH VariableYou must add the directory containing the CodeWizard libraries to your LD_LIBRARY_PATH environ-ment variable by entering one of the following commands:

• For csh or tcsh shells: setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH:/usr/local/parasoft/lib.$ARCH

• For sh, ksh, or bash shells: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/parasoft/lib.$ARCH export LD_LIBRARY_PATH

Important: Replace ARCH with the name of your architecture (aix4, alpha5, hp11, hp11_ia64, linux2,linux_ppc, sgi6, solaris).

Step 9: Set the JAVA_HOME Environment Variable (Optional)This step is optional but highly recommended.

To run RuleWizard, you need to perform one of the following tasks:

• Set your PATH to the location of your Java binaries

• Set your JAVA_HOME environment variable to the location of your Java installation directory(recommended option)

Note: RuleWizard requires JAVA 1.4.x (JDK/JRE). You can obtain this for free at http://java.sun.com.

Step 10. Modify Your EnvironmentAfter modifying the appropriate configuration files, you should execute one of the following sets of com-mands to actually modify your working environment:

• For csh or tcsh shells:source ~/.cshrcrehash

• For sh, ksh, or bash shells: . ~/.profile

Note: The '.' before ~/.profile is intentional.

8

Installation

Contacting ParasoftParasoft is committed to providing you with the best possible product support for CodeWizard. If youhave any trouble installing or using CodeWizard, please follow the procedure below in contacting ourQuality Consulting department.

• Check the manual.

• Be prepared to recreate your problem.

• Know your CodeWizard version. The number and date of your version can be seen in the ban-ner printed when running CodeWizard on one of your files.

• If the problem is not urgent, report it by e-mail or by fax.

• If you call, please use a phone near your computer. The Quality Consultant may need you torun the software while you are on the phone.

Contact Information

USA Headquarters Parasoft UK

Phone (888) 305-0041 +44 (020) 8263 2827

FAX (626) 256-6884 +44 (020) 8263 2701

Email Email: [email protected] Email: [email protected]

Parasoft France Parasoft Germany

Phone +(33 1) 64 89 26 00 +49 7805/ 956 960

FAX +(33 1) 64 89 26 10 +49 7805/ 919 714

Email Email: [email protected] Email: [email protected]

9

mailto:[email protected]




Using CodeWizard

Using CodeWizardUsing CodeWizardYou use CodeWizard by processing your source code with the special codewizard program in placeof your normal compiler. CodeWizard will then call your compiler and proceed as usual.

While processing your code, CodeWizard will detect and report various violations of good C/C++ pro-gramming practices, such as:

• Using new and delete instead of malloc and free.

• Not calling delete on pointer members in destructors.

• Not making destructors virtual in base classes.

• Avoiding breaks in for loops.

• Not comparing chars to constants out of char range.

• Avoiding assignment in if statement condition.

By default, CodeWizard sends its messages to the Insra GUI. For more information on using this GUI,see “Insra” on page 42. You can also have CodeWizard send its messages to stderr or a report file.

A Getting Started ExampleThe easiest way to learn how to use CodeWizard is to use it on an example program and see what itdoes. This section introduces one of the examples supplied with CodeWizard.

To get started, make a temporary directory and copy the source code for the example to it with com-mands similar to:

mkdir $HOME/codewizard

cd $HOME/codewizard

cp/usr/local/parasoft/codewizard/examples/item11SV.C.

Compiling and Running Without CodeWizardOnce you have copied the example program into your current directory, you can compile it with the command:

CC -g -o item11SV item11SV.C

and then run it from the shell in the normal manner:

item11SV

Notice that the program does not crash and does not print any error messages; however, this programcontains a serious problem within its coding structure.

Running CodeWizard On Item11SV.cppYou can now run CodeWizard on this simple example to see how a violation is reported. To do this, fol-low these steps:

1. Although your default compiler should have been set during installation, set it now in your cur-rent directory by adding the option:

codewizard.compiler CC

to your .psrc configuration file. For more information about .psrc files and options, see “Customizing CodeWizard Options With Configuration Files” on page 30.

10

Using CodeWizard

2. Now replace CC with codewizard on your command line:

codewizard -g -o item11SV item11SV.C

CodeWizard will analyze the code for violations and report the following message in Insra:

3. Click the ‘+” sign next to the message header to reveal the source code where the violationoccurs.

11

Using CodeWizard

4. Double-click the message header to open a message window containing the line of sourcecode where the violation occurred and an explanation of the violation detected. The messagewindow is shown below:

5. To make immediate corrections to the source code, simply double–click the excerpt of codeshown in Insra, or click the arrow in the Message window. This will open the associated file inyour selected editor, and bring you directly to the line containing the violation..

Note: By default, the command line will also be passed to the compiler, which will produce an executable.

If you want to use CodeWizard for checking only, you would type:

codewizard -Zoi "codewizard.analyze_only on" filename

This will analyze the code with CodeWizard, but will not pass it to the compiler. You may also do the same by including in your .psrc file:

codewizard.analyze_only on

For information about the .psrc file, see “Customizing CodeWizard Options With Configura-tion Files” on page 30.

Running CodeWizard From Your MakefileTo run CodeWizard from your makefile, simply replace the name of the compiler in your makefile with codewizard. For example, you could use: make CC=codewizard.

12

Preventing Errors in Embedded Development

Preventing Errors in Embedded DevelopmentCodeWizard now supports embedded development by:

• Enforcing a set of coding standards designed specifically to prevent errors in C/C++ embed-ded software development.

• Allowing you to easily create and enforce your own embedded software development codingstandards.

Enforcing Embedded Development Coding StandardsTo use CodeWizard on your embedded projects, you must compile your code with one of CodeWiz-ard’s supported compilers prior to running it through CodeWizard. You do not need to stop using yourregular compiler; rather, you should use a supported compiler before you check your code withCodeWizard, fix the problems found, then continue to compile your code with your regular compiler.

Supported CompilersSupported compilers for CodeWizard include:

Platform OS VersionC++ Compilers C Compilers

CC cxx g++ xlC aCC gcc cc

AIX4 4.3.3 X X X X

AIX5L 5.1 X X X X

HP-UX 11 (IA-64)

11i v1.5 X X X X

HP-UX 11 (PA-RISC)

11.x, 11i X X X X

IRIX 6.5.x X X X X

Linux RedHat 6.2 - 7.3 (glibc 2.1-2.2) X X

Linux_PPC Yellow Dog 2.0+ (glibc 2.1+) X X

Solaris 7, 8, 9 X X X X

13


Enabling Embedded Coding StandardsThe embedded coding standards are not enabled by default. To configure CodeWizard to enforcethese coding standards:

1. Open the .psrc file (located in your CodeWizard installation directory) in any text editor.

2. Find the line that references:

CodeWizard.rulesdirlist /.../cw_install_dir/rules/cwrules.txt

3. Replace cwrules.txt with embedded.txt.

After you have performed these initial configuration steps, CodeWizard will enforce embedded devel-opment coding standards whenever you run CodeWizard.

Creating Customized Embedded Development Coding StandardsYou can also extend and customize CodeWizard’s set of embedded development coding standardswith the RuleWizard feature that lets you graphically create your own company, personal, or tar-get-specific coding standards, as well as modify existing coding standards. For information onRuleWizard, see “Creating Custom Coding Standards” on page 17.

Embedded Development Coding StandardsThe set of coding standards designed especially for embedded software developers includes:

• ArrayElementAccess.rule

• AssignCharTooHigh.rule

• AssignCharTooLow.rule

• AssignUnCharTooHigh.rule

• AssignUnCharTooLow.rule

• BitwiseInCondition.rule

• BreakInForLoop.rule

• CastFuncPtrToPrimPtr.rule

• CastPointer.rule

• CastUnsigned.rule

• CharacterTest.rule

• CharCompareLeft.rule

• CharCompareRight.rule

• CommaOperator.rule

• ConstParam.rule

• ConstPointerFunctionCall.rule

• DeclareArrayMagnitude.rule

• DeclareBitfield.rule

• DeclareRegister.rule

• DeclareStaticLocal.rule

• DeclDimArray.rule

• DoWhile.rule

14


• EqualityFloatLeft.rule

• EqualityFloatRight.rule

• ExplicitEnumValues.rule

• ExplicitLogicalTest.rule

• ExprInSizeof.rule

• FileNameConvention.rule

• ForLoopVarAssign.rule

• FractionLoss.rule

• FuncModifyGlobalVar.rule

• FunctionSize.rule

• GlobalPrefixExclude.rule

• GlobalVarFound.rule

• HeaderInitialization.rule

• IfAssign.rule

• IfElse.rule

• ImplicitUnsignedInit.rule

• InitCharOutOfRange.rule

• InitPointerVar.rule

• InitUnCharOutOfRange.rule

• LocalVariableNames.rule

• LongConst.rule

• ManyCases.rule

• ModifyInCondition.rule

• NameBool.rule

• NameConflict.rule

• NameConstantVar.rule

• NameDouble.rule

• NameEnumType.rule

• NameFloat.rule

• NameGlobalVar.rule

• NameInt.rule

• NameIsFunction.rule

• NameLongInt.rule

• NamePointerVar.rule

• NameShortInt.rule

• NameSignedChar.rule

• NameString.rule

• NameStructType.rule

15


• NameUnsignedChar.rule

• NameUnsignedInt.rule

• NameVariable.rule

• NamingStructUnionMembers.rule

• NonScalarTypedefs.rule

• NumberFunctionParam.rule

• PassByValue.rule

• PointerParamDereference.rule

• ReferenceInitialization.rule

• SingularSwitchStatement.rule

• SourceFileSize.rule

• SourceNamingConvention.rule

• TooManyFields.rule

• UnionFieldNotDefined.rule

• UnnecessaryEqual.rule

• UnreachableCode.rule

• UnusedLocalVar.rule

• UnusedParameter.rule

• UsePositiveLogic.rule

16

Creating Custom Coding Standards

Customizing CodeWizardCreating Custom Coding StandardsCustom coding standards are rules that are specific to a certain development team, or even a certaindeveloper. There are two types of custom coding standards:

• Company coding standards. Company coding standards are rules that are specific to yourcompany or development team. For example, a rule that enforces a naming convention uniqueto your company would be a company coding standard.

• Personal coding standards. Personal coding standards are rules that help you prevent yourmost common errors. Every time you make an error, you should determine why it occurred,then design a personal coding standard that prevents it from reoccurring. If you do this on aregular basis, you will quickly build a set of coding standards that can prevent your most com-mon errors from entering your code.

CodeWizard’s RuleWizard feature lets you design custom coding standards by graphically expressingthe pattern that you want CodeWizard to look for during automatic coding standard enforcement. Asshown in the following graphic, rules are created by selecting a main "node," then adding additionalelements until the rule expresses the pattern that you want to check for. Rule elements are added bypointing, clicking, and entering values into dialog boxes. You can also use this tool to customize manyof CodeWizard’s built-in coding standards.

To launch RuleWizard, type rulewizard at the prompt. A complete user’s guide is available inRuleWizard; to access this user’s guide, choose Help> View in the RuleWizard GUI. Refer to theRuleWizard User’s Guide for information about creating, enforcing and enabling/disabling rules. TheRuleWizard GUI is shown in the following graphic:

17

Creating Custom Coding Standards

18

Customizing Output With Suppressions

Customizing Output With SuppressionsSuppressions stop CodeWizard from enforcing certain coding standards. You can use suppressions totailor CodeWizard's output to your development team and the current project. By default, CodeWizardis configured to suppress all violations in the Universal Coding Standard category and all violations thathave an Informational severity, and to unsuppress any enabled User items.

Topics discussed in this section include:

• “How Suppression Options Work”

• “Adding a Suppression Option”

• “Deleting a Suppression Option”

• “Moving a Suppression Option”

• “Determining Where Suppression Options Are Saved”

• “Suppressing Errors within the Source File”

• “An Example With Suppressions”

How Suppression Options WorkSuppression options are read from top to bottom when CodeWizard determines which item violationswill be reported and which will be suppressed. Because of this, you can think of a series of suppressionoptions as a series of sieves that remove options as they pass through from top to bottom of the sup-pressions page. Conversely, unsuppress options can restore violations that were screened out by ear-lier suppress options. This can get complicated when many suppress and unsuppress options arebeing used concurrently, but offers a very powerful method of controlling the messages that will be dis-played.

19


The following flow chart illustrates one simple example.

item 2, item 3,... item 39, item ....

Unsuppressitem 3

SuppressAll

item 3

Suppressitem3

Unsuppressitem 2

item 2, 3

item 2

Violations Reported

Suppression Option

Violations Reported

Violations Reported

Suppression Option

Suppression Option

Suppression Option

Violations Reported

Violations Reported

20


Adding a Suppression OptionYou can enter suppressions in the Suppressions Control Panel, which is accessible by clicking theSuppress button in Insra when Insra is running and contains violations.

To add a new suppression option, place your cursor in the table row where you want the suppressionoption inserted, then click the Insert button. As is, this new option will suppress all violations reportedby CodeWizard.

To determine exactly what violations this option suppresses (or unsuppresses), edit its various fields.Each field can be modified to restrict the messages that will be suppressed or unsuppressed. Theavailable fields are:

• “The Action Field”

• “The Persistence Field”

• “The Item Field”

• “The Type Field”

• “The Class Field”

• “The File Field”

• “Add Lines Field”

• “The Notes Field”

The Action FieldThis field specifies whether the violation message listed is to be suppressed (as indicated by a speakerwith an X through it) or unsuppressed (indicated by a speaker with no X through it). Double clicking onthe field toggles between suppressing and unsuppressing the violation message.

The Persistence FieldThis field specifies whether the suppression option will be saved to the .psrc file under which it islisted. Double-clicking this field toggles it from persistent (the field is checked) to temporary (the field isunchecked). Options marked as persistent will be added to the appropriate .psrc files when the Savebutton is clicked on. Options marked as temporary will be discarded.

Options with an X in this field cannot be made persistent, either because they are hardwired orbecause the file in which it is placed is not writable. New suppression options are marked as persistentby default.

21


The Item FieldThe Item field lets you determine the item violation that you would like to suppress or unsuppress. Bydefault, there is an asterisk present, which signifies that all items are suppressed or unsuppressed(depending on which option you selected in the Action field).

To enter the item number, double-click in the Item field. A text field will open. Enter the item that you want to suppress or unsuppress in the text field, then press Enter.

Choose the item that you would like to suppress or unsuppress. * matches all item numbers. The prefix"ecpp" stands for Effective C++, "mecpp" for More Effective C++, "mk" for Meyers-Klaus, and "ucs" forUniversal Coding Standards; "user" is used to indicate rules created in RuleWizard or built-in rules thatcan be modified in RuleWizard.

The Type FieldThe Type field allows you to select the type of violation for which messages will be suppressed orunsuppressed. To select the type, double-click the Type field. A pull-down menu button will appear.

This menu contains the following options (in increasing order of seriousness):

• I Informational (suppressed by default)

• PV Possible Violation

• V Violation

• PSV Possible Severe Violation

• SV Severe Violation

* Matches all types

22


The Class FieldThe Class field allows you to enter a class for which messages will be suppressed or unsuppressed. Afield containing only "*" will match all classes To enter the class, double-click the Class field. A text fieldwill open. Enter the desired class name in the text field, then press Enter.

The File FieldThis field allows you to enter a file for which messages will be suppressed or unsuppressed. A fieldcontaining only "*" will match all files. To enter a file name, type it in the File field, or double-click theFile field and select a file using the file chooser that opens.

23


Add Lines FieldThis field allows you to enter line numbers for which messages will be suppressed or unsuppressed. Afield containing only "*" will match all lines. To enter a line statement, type it in the Line field. Availablestatements include:

• 2 - line 2

• 2-10 - lines from 2 to 10

• *-10 - lines less and equal 10

• 2-* - lines equal and greater than 2

• * or *-* - all lines

You can type more than one line statement per line by using a comma as a separator (don't use whitespaces between line numbers and the commas). For example: *-4,7,9-12,15-* - indicates thatyou want to look at lines 1 to 4, then line 7, then from lines 9 to 12, and then from line 15 to the end.

The Notes FieldThis field allows you to create notes to explain the purpose of the current suppression item. To enter anote, double-click the Note field. A text field will open. Enter the desired note in the text field, thenpress Enter.

24


Deleting a Suppression OptionTo delete a suppression option, click it to select it, then click the Delete button.

Once this deletion has been applied, the effects of this option will be gone. This change will appear inInsra immediately.

Moving a Suppression OptionYou may move individual suppression options into new locations on the suppressions page by clickingthe Up and Down buttons. This will affect how CodeWizard reports item violations. For more informa-tion on this topic see “How Suppression Options Work” above.

Determining Where Suppression Options Are SavedThe headers in Insra show the various locations in which .psrc files reside. Insra will display the sup-pression options as read from each file under the appropriate header. When you add a new option using the Insert button, it will be inserted below the currently selected option. You can then move it into the file in which you would like it saved, or mark it as temporary by double-clicking the persistence field (see above). There are two special locations where suppression options may reside other than actual .psrc files: hardwired options and command line options. The former are set internally by CodeWizard, and therefore cannot be permanently changed. They can be edited and/or removed in the window tem-porarily, however. The latter are options passed using the -Zop and -Zoi options on the command line. These options, like hardwired options, cannot be made persistent, but can be moved into a .psrc file if you decide that you want to make them permanent.

Suppressing Errors within the Source FileYou can use #pragma to suppress CodeWizard errors within the source file. In the following example,CodeWizard will suppress the first MECPP item 2 violation while allowing the second:

source file:int main() { char *pc1 = 0; char *pc2 = 0; #pragma CodeWizard OFF pc1 = (char *)pc2; // suppressed #pragma CodeWizard ON pc1 = (char *)pc2; // MECPP item 2 Violation return 0; }

This option is useful if you are debugging code and want to skip a line, a set of lines, or a small block ofcode that you know contains errors but that you do not want to appear as part of your CodeWizard vio-lations report.

25


Using #pragma suppress/unsuppress DirectivesCodeWizard Version 4.3 allows users to define suppressions directly in their source code, using#pragma codewizard suppress and #pragma codewizard unsuppress directives.

This feature allows for fine-grained control over which rules are enforced on files, classes, or even atthe line level. Another advantage is that since these directives are placed in the sources being ana-lyzed, the suppressions are kept together with the code they apply to. Therefore, it is very easy to havea given set of suppressions visible among all developers working on source files containing such direc-tives.

When running static analysis, all such directives are collected and applied to filter out unwanted viola-tion reports. To specify suppression information the following directive should be used in the sourcecode:

#pragma codewizard suppress <pattern>

To specify unsuppression information the following directive should be used in the source code:

#pragma codewizard unsuppress <pattern>

<pattern> may be any of the following:

1. item RULE_IDENTIFIER (e.g.: item user-200, item ecpp-*)

2. class CLASS_NAME (e.g.: class MyClass, class *)

3. file FILE_NAME (e.g.: file example.cpp, file ex*.cpp)

4. line LINE_NUMBER (e.g.: line *, line 10, line 50-*)

5. all

Elements 1 through 4 can be combined together by separating each entry with a space, as shown inexamples below.

Example A:#pragma codewizard suppress item mecpp-02

This suppresses reports of violation mecpp-02 for the current file, starting from the line where the sup-pression is located.

Example B:#pragma codewizard unsuppress item * class MyClass line 10-*

This unsuppresses all items for class MyClass in the current file starting from line 10.

Example C:#pragma codewizard unsuppress item user-250 file example.cpp

This unsuppresses the item user-250 in the file example.cpp for the current compilation unit.

Example D:#pragma codewizard suppress all

This suppresses all messages in the current file starting from the line where this directive was entered.

26


Additional Notes• When no item is specified, (un)suppression will be applied to all rules. This is equivalent to

specifying item *.

• When no file is specified, (un)suppression will be applied only to the current file.

• When no line is being specified, (un)suppression will be applied starting from the line thatcontains the directive.

• To suppress files with whitespaces in their names, quotes should be used. For example:

#pragma suppress file "file with whitespace.cpp"

• Putting suppression with file * pattern in a header file makes it valid for all the files thatinclude that header file. When no file is specified, suppression will be applied only to thatheader.

An Example With SuppressionsThis section shows how to use suppressions by building upon the examples given in the UsingCodeWizard section.

For example, let’s assume that you have just run the simple example, then have decided that you wantto unsuppress all violations of rule ucs-19. This rule states that a class that has pointer members shallhave an operator= and a copy constructor. Adhering to this rule prevents memory leaks and datacorruption. If you do not define a copy constructor, the default constructor will be used, which is usuallynot the desired behavior when a class has pointer members.

To have CodeWizard report all violations of ucs-19 that it finds in all files that it analyzes, perform thefollowing steps:

1. To open the Suppressions Control Panel, click the Suppress button in Insra when Insra con-tains one or more violations.

2. In the Suppressions Control Panel, place your cursor in the last row of suppressions, then clickthe Insert button. An additional row of asterisks will appear.

3. In the new suppression option’s Action field, choose Unsuppress by clicking the speaker iconuntil the speaker does not have an X over it.

4. In the new suppression’s Item field, enter ucs-19.Save your new suppression by clicking Save.The Insra GUI will then report that a violation of the ucs-19 rule occurred in item11SV.C.

27

Global Reporting System

28

Static Analysis RulesGlobal Reporting SystemCodeWizard 4.3 allows you to report coding violations detected during source code analysis to the Glo-bal Reporting System (GRS) server. This provides a single place to store reports from CodeWizardprocesses running on multiple machines (for example, during nightly builds).

Before enabling the GRS support, make sure you have the following information from your systemadministrator:

• The GRS server's host name or the IP address.

• The port on which the GRS server is waiting for connections from the clients (that is, fromCodeWizard processes).

Using the GRS ServerFollow the directions given below to configure CodeWizard to send reports to the GRS server.

Enabling the GRS Server for UNIX SystemsTo enable GRS server support for UNIX systems you must add appropriate GRS options to your.psrc file, as described below:

1. The CodeWizard.report_file option must include the grs pseudo-file. This will tellCodeWizard that it should send results to the GRS server.

For example:

• To enable sending results to the GRS server only:

CodeWizard.report_file grs

• To enable sending results to both Insra viewer and the GRS server:

CodeWizard.report_file insra; grs

• To enable sending results to the Insra viewer, the GRS server, and the standard out-put:

CodeWizard.report_file insra; grs; stdout

• To enable sending results to the GRS server and a file called "report.txt":

CodeWizard.report_file grs; report.txt

2. Specify the GRS server hostname and port number by adding the following entries in your.psrc file:

• CodeWizard.GRS_server_host <GRS-server-hostname -or-IP-address>

• CodeWizard.GRS_server_port <GRS-server-port-number>

For example:

• CodeWizard.GRS_server_host grs.server.machine

• CodeWizard.GRS_server_port 32323

Disabling the GRS Server for UNIX SystemsTo disable the GRS server support for UNIX systems, simply remove the grs pseudo-file from theCodeWizard.report_file setting in your .psrc file.

Oracle Proc Files

29

Oracle Proc FilesCodeWizard supports processing of Oracle Proc (*.pc) files for use in embedded SQL programs.CodeWizard dynamically suppresses errors inherited from Proc generated code, allowing you to focuson errors that CodeWizard finds within your own source code.

Note: All Oracle Proc support is for command line usage only. The following instructions provide onlypartial support from the command line.

To run CodeWizard on Proc files in the UNIX space, the environment must first be configured:

1. Install Oracle Proc.

2. Ensure that the binary file *proc is accessible from the command line.

3. Do not mix the different versions of Oracle Proc.

4. Pass all necessary include directories to CodeWizard.

Now it is possible call CodeWizard.

• Using Proc to generate 'c' file call:

codewizard $(ALL_INCLUDES) proc_file.pc

• Using Proc to generate 'c++' file call:

• codewizard $(ALL_INCLUDES) proc_file.pc -Zoi "procflags CODE=CPP". In .psrc files, use codewizard.procflags CODE=CPP.

If your proc_file does not have a standard *.pc extension, use the ‘-Zproc’ option to force Proc mode:

codewizard $(ALL_INCLUDES) -Zproc proc_file.PROC -Zoi "procflags CODE=CPP"

Makefile ExampleThe following is an example of an Oracle Proc makefile:

ORACLE_HOME=$(HOME)/oracleORACLE_INCLUDES = -I$(ORACLE_HOME)/precomp/public \ -I$(ORACLE_HOME)/rdbms/demo \ -I$(ORACLE_HOME)/rdbms/public \ -I$(ORACLE_HOME)/plsql/public \ -I$(ORACLE_HOME)/network/publicPROCOPTIONS= CODE=CPP PARSE=NONE NLS_LOCAL=YES

Within CodeWizard, to use this makefile call:

codewizard -Zoi "procflags $(PROCOPTIONS)" $(ORACLE_INCLUDES) proc_file.pc

Customizing CodeWizard Options With Configuration Files

Customizing CodeWizard Options With Configuration FilesCodeWizard reads options from files called .psrc, which may exist at various locations in the file sys-tem. These options control the behavior of CodeWizard and other Parasoft tools. The files are pro-cessed in the order specified below:

• The file .psrc in the appropriate lib and compiler subdirectories of the main Parasoft installa-tion directory. For example:/usr/local/parasoft/lib.linux/CC/.psrc

• The file .psrc in the main installation ($PARASOFT) directory. For example: /usr/local/parasoft/.psrc

• A file .psrc in your $HOME directory, if it exists.

• A file .psrc in the current working directory, if it exists.

• Files specified on the command line with -Zop and/or -Zoi to the codewizard command in theorder present on the command line.

In each case, options found in later files override those seen earlier. All files mentioned above will beprocessed and the options set before any source files are processed.

Typically, compiler-dependent options are stored in the first location, site-dependent options are storedin the second location, user-dependent options are stored in the third location, and project-dependentoptions are stored in the fourth location. -Zop is commonly used for file-dependent options, and -Zoi iscommonly used for temporary options.

FormatCodeWizard configuration files are simple ASCII files created and modified with a normal text editor.

Entries which begin with the character `#' are treated as comments and ignored, as are blank lines.

All keywords can be specified in either upper or lower case, and embedded underbar characters (`_')are ignored. Arguments can normally be entered in either case, except where case has specific mean-ing, such as in directory or file names. If a line is too long, or would look better on multiple lines, youcan use the ‘\’ character as a continuation line.

Option ValuesThe following sections describe the interpretation of the various parameters. Some options havedefault values, which are printed in the following section in boldface.

30


FilenamesSeveral CodeWizard options can specify filenames for various configuration and/or output files. Youmay either enter a simple filename or give a template which takes the form of a string of charactersincluding tokens such as those in the following table, environment variables, and the `~' character.Each of these is expanded to indicate a certain property of your program as indicated in the followingtable.

Thus, the template:

report_file $HOME/codewizard/%a/%c/foo.C.out

will cause CodeWizard to write its output to a file with a name such as:

/usr/me/codewizard/linux/CC/foo.C.out

in which the environment variable HOME has been replaced by its value and the `%a' and `%c'tokens have been expanded to indicate the architecture and compiler name in use.

Using -Zop and -ZoiOn the command line, the -Zop and -Zoi options are processed from left to right, after all other .psrcfiles, and before processing any source code. Therefore, the following command line would tellCodeWizard to analyze all the files using the CC compiler.

codewizard -Zoi "compiler g++" foo.C -Zop foo.def foo2.C -Zoi "compiler g++" foo3.C -Zoi "compiler CC"

foo.def:compiler CC

Options passed using -Zoi do not require the codewizard prefix as options passed in .psrc or -Zopfiles do. With -Zoi, the appropriate prefix is implicitly added using the name of the command to whichthe -Zoi is being passed.

Key Meaning

%a Machine architecture on which you are running, for example, linux, rs6000, hp, and so on.

%c Abbreviated name of the compiler you are using, for example, CC, gcc, xlC, and so on.

%d Time of program compilation in format: YYYYMMDDHHMMSS

%p Process I.D.

%r CodeWizard version number, for example, 4.1

%R CodeWizard version number without ‘.' character. For example, version 4.1 becomes 41.

31


Options Used by CodeWizard1. codewizard.analyze_only [on|off]

Specifies whether CodeWizard should pass the file to the compiler or just check for item viola-tions (the default). Turning this option to off tells CodeWizard to pass the file on to the compilerafter checking for item violations.

2. codewizard.buildinruleload

Using this option, CodeWizard loads particular built-in rules. For example, use the name of abuilt-in rule you wish to load, such as ucs-24. You can choose to load all rules by enteringcodewizard.buildinruleload all.

3. codewizard.buildinruleremove

Using this option, CodeWizard removes particular built-in rules. For example, use the name ofa built-in rule you wish to remove, such as ucs-24. You can choose to remove all rules byentering codewizard.buildinruleremove all.

4. codewizard.c_as_cpp [on|off]Specifies whether files with the .c extension should be treated as C++ source code. With thisoption off, CodeWizard will treat files with the .c extension as C code only. If you use C++code in .c files, you should turn this option on.

5. codewizard.compiler compiler_name

Specifies the name of an alternative compiler, such as gcc. If your new compiler is not recog-nized by CodeWizard, you may have to set the compiler_acronym option. This option over-rides the compiler_* options: compiler_acronym, compiler_c, compiler_cpp, andcompiler_default. The indicated compiler will be called every time codewizard is called.

6. codewizard.compiler_acronym abbreviation

Specifies the colloquial name of an alternative compiler, such as gcc. This name is used tolocate the appropriate .psrc files. It does not indicate which compiler will actually be called tocompile source files (see the other compiler_* options). This option overrides thecompiler_c, compiler_cpp, and compiler_default options. In addition, this optionmust be placed after the active compiler option. The order must be:

compiler c89

compiler_acronym cc

and not vice-versa. This option defaults to the last path component of your compiler's name,with the exception of the System V compatibility compiler on Sun workstations(/usr/5bin/cc), which has the acronym 5cc.

7. codewizard.compiler_c C_compiler_name

Specifies the name of the default C compiler, such as gcc. This compiler will be called for any.c files. The default is cc. This option is overridden by the compiler andcompiler_acronym options.

32


8. codewizard.compiler_cpp C++_compiler_name

Specifies the name of the default C++ compiler, such as g++. This compiler will be called forany .cc, .cpp, .cxx, and .C files. The default is platform dependent: cxx for Alpha, g++ forLinux, xlC for RS/6000, and CC for other platforms. This option is overridden by the compilerand compiler_acronym options.

9. codewizard.compiler_default [c|cpp]

Specifies whether the default C or C++ compiler should be called to link when there are nosource files on the link line. This option is overridden by the compiler andcompiler_acronym options.

10. codewizard.compiler_flags flags

CodeWizard will add the flags whenever you compile your program (but they will not bepassed to the preprocessor).

11. codewizard.compiler_keyword [*|const|inline|signed|volatile] keyword

Specifies a new compiler keyword (by using the *) or a different name for a standard keyword.For example, if your compiler uses __const as a keyword, use the option:

compiler_keyword const __const

12. codewizard.compiler_options keyword value

Specifies various capabilities of the compiler in use, as described in the following table:

Keyword Value Meaning

ansi None Assumes compiler supports ANSI C (default).

<type> bfunc Function name

Specifies that the indicated function is a compiler "built-in" that is dealt with specially. The optional type keyword specifies that the built-in has a return type other than int. Currently, only long, double, char *, and void * types are supported.

btype Type name

Specifies that the named type is a "built-in" that is treated specially by the compiler.

bvar Variable name

Specifies that the named variable is a "built-in" that is treated specially by the compiler.

esc_x Integer Specifies how the compiler treats the ‘\x’ escape sequence. Possible values are: 0: treat ‘\x' as the single character ‘x' (Kernighan & Ritchie style). -1: treat as a hex constant. Consume as many hex digits as possible. >0: treat as a hex constant. Consume at most the given number of hex digits.

33


13. codewizard.error_format string

Specifies the format for error message banners generated by CodeWizard. The string argu-ment will be displayed as entered with the macro substitutions taking place as shown in the fol-lowing table. The string may also contain standard C formatting characters, such as ‘\n’.

for_scope nestednot-nestedoptional

Specifies how for(int i; ...; ...) is scoped. Possible values are: nested: New ANSI standard, always treat as nested. notnested: Old standard, never treat as nested. optional: New standard by default, but old-style code is detected and treated properly (and silently).

knr None Assumes compiler uses Kernighan and Ritchie (old-style) C.

loose None Enables non-ANSI extensions (default).

namespaces None Specifies that namespace is a keyword (default).

no- namespaces

None Specifies that namespace is not a keyword.

promote_long

None If this option is found, integral data types are promoted to long in expressions, rather than int.

sizet d,ld,u, lu Specifies the data type returned by the sizeof operator, as follows: d = int, ld = long, u = unsigned int, lu = unsigned long.

strict None Disables non-ANSI extensions (compiler dependent).

xfunctype Function name

Indicates that the named function takes an argument which is a data type rather than a variable (for example, alignof).

Key Expands to

%b Error message included in output component.

%c Error category (and sub-category if required).

%C Name of the class in which the error occurred.

%d Date on which the error occurs. (DD-MON-YYYY).

%f Filename containing the error.

%F Full pathname, including directories, or the file containing the error.

%h Name of the host on which the application is running.

%l Line number containing the error.

34


14. codeWizard.exit_code_threshold [0|1|2|...]

This option tells CodeWizard to return non-zero exit code if the number of reported violations isgreater or equal to this option's value. The default value is 0 (zero).

For example, if the parameter is set to 5, and 5 or more violations are found in the analyzedcode, then CodeWizard will exit with non-zero exit code to indicate this situation.

Set this value to 1 if CodeWizard should exit only if there are no violations in the code. Settingthis option to 0 (zero) disables this mechanism, thus telling CodeWizard to always exit withzero no matter how many violations are found.

15. codewizard.file_ignore <full_path_to_any_directory>/*

Specifies which files you do not want CodeWizard to analyze. No item violations from thesefiles will be displayed by CodeWizard.

16. codeWizard.grs_server_host GRS_server_host

Specify here the name of IP address of GRS server, which will receive CodeWizard messages.

17. codeWizard.grs_server_port GRS_server_port

Specify here the port number of GRS server, which will receive CodeWizard messages. Thedefault is 32323, but it may have to be set to a different value depending on configuration ofthe GRS server in the local network.

18. codewizard.max_call_stack_depth [1|2|3|...]

Specifies how deeply CodeWizard should traverse the call stack in checking for violations.This option currently only affects item 16, which suggests that operator= should assign alldata members. With the default setting of 1, CodeWizard will see all assignments made inoperator= and any function called by operator=. However, if one of the functions called byoperator= calls another function which assigns a data member, CodeWizard will not see thisassignment and will report a violation. With this option set to 2, CodeWizard will see theassignment and will not report a violation.

19. codewizard.msgsrcsize [0|1|2|3|...20]

used to indicate how many source lines should be include in the error message. Available inStandard out, Standard error and Report file.

%p Process ID of the process incurring the error.

%t Time at which the error occurred. (HH:MM:SS).

%v The severity level of a violation.

%V Brief description of violation.

35


20. codewizard.okmessage [message]

message you would like diplayed when CodeWizard doesn’t find any bugs. Available in Stan-dard out, Standard error, and Report file.

21. codewizard.optionfile [option] file

Directs CodeWizard to read the specified file as a .psrc file. If [option] is specified, then itinterprets every line in the file as arguments to the option.

22. codewizard.preprocessor_flag flag

Specifies a flag or flags that can safely be passed to the preprocessor. Any flags on CodeWiz-ard command lines that are not listed in a preprocessor_flag statement will be strippedfrom the command before invoking the preprocessor. The list of pre-processor flags is usuallymaintained in the file:

<install_dir>/lib.$ARCH/$COMPILER/.psrc

Flags specified by this option will be passed to the preprocessor only, unless they are alsospecified in a preprocessor_propagate_flag option.

23. codewizard.preprocessor_propagate_flag flag

Specifies a flag or flags that should be passed to both the preprocessor and the compiler. If theflag is not listed in a preprocessor_flag option, this option will be ignored.

24. CodeWizard.proc_flags <flags>

This option specifies additional flags to be passed to the Oracle Proc. For more information,See “Oracle Proc Files” on page 29.

25. codewizard.report_banner [on|off]

Controls whether or not a message is displayed on your terminal, reminding you that errormessages have been redirected to a file.

26. codewizard.reportfile output;output

Specifies the name of the report file(s), using semi-colons (;) as separators. Environment vari-ables and various pattern generation keys may appear in filename. Add options for the particu-lar report type needed. Options include:

• insra for the Insra GUI

• stdout for standard output

• stderr for standard error

• grs to send results to the GRS server

• filepath for the path to the report file

For example, to send reports to both insra and standard error use reportfileinsra;stderr;/tmp/myfile.txt

36


27. codewizard.report_overwrite [on|off]

If set to off, error messages are appended to the report file rather than overwriting it on eachrun.

28. codewizard.rulefile <rule/file/path>

Using this option, the user can analyze source code against one particular rule. For example,to load a given rule:

CodeWizard.rulefile ./cw_install_dir/rules/paramnameinprototype.rule

(Note: ignore the line break in this example; this is due to space restrictions on the manualpage. A space comes between the word rulefile and the ./).

29. codewizard.rulesdirlist filename

Specifies the path to a text file that lists a set of user-defined .rule files that you CodeWizard toenforce; the rules listed in the text file must be contained in the same directory as the text file.By default, this option is set to <codewizard_install_dir>/rules/ cwrules.txt. You may have morethan one rulesdirlist entry.

30. codewizard.ruleset NAME PATH

NAME is the identifier. PATH is the absolute location of shared libraries. Set PATH to empty tonot load libraries. Basic libraries that come with CodeWizard are Effective C++, More EffectiveC++, MK, and UCS.

31. codewizard.skipduplicatedmessages [yes|no]

Using this option, CodeWizard collects all triggered messages and skips those that are dupli-cates, that is, that have already been triggered.

For example, skipduplicatedmessages yes.

32. codewizard.support [support_type]

Using this option, CodeWizard creates additional files for support. Add options for the particu-lar support type needed. Options include:

• source for source file

• log for log files

• preprocessed for preprocessed files

For example, support log preprocessed to create both a log file and a preprocessed filefor support purposes.

33. codewizard.supportpath [pathname]

Use this option to save your support results to a particular location. For example, support-path tmp/cwsupportdir.

37


34. codewizard.suppress [class <name>] [file <name>] [item <number>] [line <number(s)>] [typeI|PSV|PV|SV|V] [all]

Suppresses violations matching the indicated suppression codes. Only one of each type ofsuppression category is allowed per line. For example:

suppress class foo file foo.c item ecpp-2 line *-10 type I

is allowed, but:

suppress class foo class bar

is not.

Of course, multiple lines are permissible, with later unsuppress options superseding earliersuppress options (and vice-versa) if there are common categories. The all category sup-presses all messages. It can be used in conjunction with subsequent unsuppress options toturn on a limited set of messages.

The line field allows you to enter a number of lines for which messages will be suppressed orunsuppressed. A field containing only "*" will match all lines. Available statements:

• 2 - line 2

• 2-10 - lines from 2 to 10

• *-10 - lines less and equal 10

• 2-* - lines equal and greater than 2

• * or *-* - all lines

You can type more than one line statement per line by using a comma as a separator (don'tuse white spaces between line numbers and the commas). For example: *-4,7,9-12,15-*- indicates that you want to look at start to 4, then 7, then from 9 to 12, and then from 15 to theend.

35. codewizard.suppress_c_structs [on|off]

Suppresses item violations in C structs using a heuristic method. Turning this option to off willdisable this method, and may result in some incorrect item violations.

36. codewizard.suppress_file string

This option tells CodeWizard not to report any violations from files which match the string. Thestring should be a glob-style regular expression and should include the full path. This optionoverrides any suppress options. To see violations from the files covered by this option, you willneed to remove it. The unsuppress option will not unsuppress violations from these files.

37. codeWizard.suppress_line_with_function_macro [on|off]

This option is used to suppress messages originating from code that was created by expand-ing function-like macros.

This suppression applies only to macros defined in suppressed header files (for example,using the "CodeWizard.suppress_file" option). The default value is on.

38


38. codeWizard.suppress_line_with_macro [on|off]

This option operates exactly as the option "CodeWizard.suppress_line_with_function_macro".It is provided for backward compatibility only.

39. codeWizard.suppress_line_with_simple_macro [on|off] This option suppresses messages originating from code that was created by expanding simple(not function-like) macros. This suppression applies only to macros defined in suppressedheader files (for example, using the "CodeWizard.suppress_file" option). The default value isoff.

40. codewizard.suppress_warning code

Suppresses parser warnings matching the indicated code. The code should match the numeri-cal code CodeWizard prints with the warning message you would like to suppress. The codescorrespond to the chapter, section, and paragraph(s) of the draft ANSI standard on which thewarning is based. For example, to suppress the warning:

Warning:12.3.2-5: return type may not be

specified for conversion functions

add the following line to your .psrc file.

suppress_warning 12.3.2-5

41. codewizard.temp_directory path

Specifies the directory where CodeWizard will write its temporary files, for example, /tmp. Thedefault is the current directory.

42. codewizard.textanalyzeheader [yes|no]

Configures CodeWizard to analyze included headers using textwizard analyze feature.

For example, textanalyzeheader yes.

43. codeWizard.text_analyze_only [on|off] This option tells CodeWizard to perform analysis using text rules only (that is, only RuleWiz-ard's "C++Text" dictionary will be used during analysis). This option also implies that only agiven source file will be checked — all included files will be ignored. The default value is off.

44. codewizard.timestamp YYYY-MM-DD

CodeWizard will not check a file if its modification date is older than its timestamp date.Acceptable date format is YYYY-MM-DD.

45. codewizard.unsuppress [class <name>] [file <name>] [item <number>] [line <number(s)>][type I|PSV|PV|SV|V] [all]

Unsuppresses violations matching the indicated suppression codes. For more details on howto properly use this option, see the suppress option.

39


Options Used by InsraRunning Insra

1. insra.body_background_color [White|color]

Specifies the color Insra will use for the message body area background.

2. insra.body_font [Fixed|font]

Specifies the font Insra will use for the message body text. On some systems, for example,SGI, the Fixed font is much too large. This option can be used to select a smaller font.

3. insra.body_height [0|1|2|...|80|...]

Specifies the starting height of the Insra message body area in number of rows of visible text.This may be modified while Insra is running using the standard Motif controls.

4. insra.body_text_color [Black|color]

Specifies the color Insra will use for the message body text.

5. insra.body_width [0|1|2|...|80|...]

Specifies the starting width of the Insra message body area in number of columns of visibletext. This may be modified while Insra is running using the standard Motif controls. If this optionis set to a different value than header_width, the larger value will be used.

6. insra.header_background_color [White|color]

Specifies the font Insra will use for the message header area background.

7. insra.header_font [Fixed|font]

Specifies the font Insra will use for the header body text. On some systems, for example, SGI,the Fixed font is much too large. This option can be used to select a smaller font.

8. insra.header_height [0|1|2|...|80|...]

Specifies the starting height of the Insra message header area in number of rows of visibletext. This may be modified while Insra is running using the standard Motif controls.

9. insra.header_highlight_color [LightSteelBlue2|color]

Specifies the color Insra will use to indicate the currently selected message or session headerin the message header area.

40


10. insra.header_highlight_text_color [Black|color]

Specifies the color Insra will use for the text of the currently selected message or sessionheader in the message header area.

11. insra.header_session_color [Black|color]

Specifies the color Insra will use to indicate a session header.

12. insra.header_text_color [Black|color]

Specifies the color Insra will use to for session header text.

13. insra.header_width [0|1|2|...|80|...]

Specifies the starting width of the Insra message header area in number of columns of visibletext. This may be modified while Insra is running using the standard Motif controls. If this optionis set to a different value than body_width, the larger value will be used.

14. insra.port [3255|port_number]

Specifies which port Insra should use to communicate with CodeWizard.

15. insra.toolbar [on|off]

Specifies whether Insra's toolbar is displayed. All toolbar commands can also be chosen fromthe menu bar.

16. insra.visual [xterm -e vi +%l %f|emacs +%l %f]

Specifies how Insra should call an editor to display the line of source code causing the error.Insra will expand the %l token to the line number and the %f token to the file name before exe-cuting the given command. It is important to include the full path of any binary that lives in alocation not on your path. Setting this option with no command string disables source browsingfrom Insra.

41

Insra

Viewing Results in InsraInsraInsra is a graphical user interface for displaying violation messages generated by CodeWizard. Themessages are summarized in a convenient display, which allows you to quickly navigate through thelist of violation messages, suppress messages, invoke an editor for immediate corrections to thesource code, and delete messages as violations are fixed.

Topics discussed in this section include:

• “The Insra Display”

• “Sending Messages to Insra”

• “Viewing and Navigating”

• “Deleting Messages”

• “Suppressing Messages”

• “The Suppressions Tool Bar”

• “Miscellaneous Issues”

• “Troubleshooting”

• “Help”

The Insra DisplayStatus BarDuring analysis, CodeWizard makes a connection to Insra each time a violation is detected. The statusbar will report the number of violation messages currently being displayed and the number of activeconnections. An active connection is denoted by a yellow star to the left of the session header. A con-nection will remain active as long as the program is still compiling/running. Insra will not allow you todelete a session header as long as its connection remains active, and you may not exit Insra until allconnections have been closed.

Tool BarToolbar

Session Header

Message Header

Status Bar

42

Insra

The tool bar allows you to:

• Scroll up and down through messages.

• Delete selected messages as bugs are fixed.

• Suppress violations detected by CodeWizard.

• Sort messages by order (time) reported, violation category, or directory and file.

• Kill the selected active connection.

Message Header AreaThe message header area contains session headers and message headers for programs currentlyconnected to Insra.

Session HeaderWhen the first violation is detected for a particular compilation or execution, a session header is sent toInsra. The session header includes the following information:

• Compilation/execution

• Source file/program

• Host on which the process is running

• Process ID

Message HeaderMessage headers generated by CodeWizard include:

• Item violated and severity of violation

• File name

• Line number of violation

All messages sent to Insra are marked with a special icon. Refer to the following table for a briefdescription of each icon.

Clicking the ‘+” sign next to the message header will reveal the source code where the violation occurs.Double-clicking a message header brings up a Message window.

Icon Explanation

CodeWizard violation message

Trapped signal

43

Insra

Error Message WindowThe Message window opens when you double-click a message header. This window contains the vio-lation message for the selected message header.

CodeWizard’s Message window contains:

• The line of source code where the violation occurred.

• An explanation of the violation detected.

To make immediate corrections to the source code, simply double-click the excerpt of code shown inInsra, or click the arrow in the Message window. This will open the file in a text editor, and bring youdirectly to the line containing the violation..

Sending Messages to InsraBy default, both CodeWizard sends output messages to Insra. You may choose to send your output toanother location, such as stderr, stdout, or a report file of your choice. To change your output loca-tion, you would enter the following line to your .psrc file:

codewizard.report_file <filename>

The option:

codewizard.runtime.report_file insra

will send only runtime messages to Insra. Compile-time messages will be sent to stderr.

The option:

codewizard.compile.report_file insra

will send only compile-time messages to Insra. Run-time messages will be sent to stderr.

To direct messages back to Insra, simply replace the above line with the following line in your .psrcfile:

codewizard.report_file insra

Your compile-time and run-time messages will be sent to Insra. When CodeWizard is configured tosend output to Insra, CodeWizard attempts to establish a connection to Insra each time a violation isdetected. If Insra is not yet running, it will automatically start. Once the connection is established, asession header and all corresponding message headers will be reported in the order they were

44

Insra

detected. Each new compilation or program, with its own session header and messages, will be dis-played in the order in which it connected to Insra. To change your output location using the commandline, see “Customizing CodeWizard Options With Configuration Files” on page 30.

Viewing and NavigatingMessage headers sent to Insra are denoted by specific icon. (See “The Insra Display”). The body of thecurrently selected message is displayed in a separate Message window. Double-click the messageheader to view the message itself. The message header area and the Message window are both resiz-able, and scroll bars are also available to access text that is not visible. Currently active messagesbecome inactive when they are deleted or suppressed

Deleting MessagesOnce violation messages have been read and analyzed, you may wish to clear them from the window.The Delete button on the Insra tool bar allows you to remove messages from the display as violationsare corrected in your code. A message or an entire session may be removed by selecting the corre-sponding entry in the message header area and clicking the Delete button. A message can also bedeleted by selecting Messages> Delete from the menu bar.

Suppressing MessagesYou can use suppressions to tailor CodeWizard's output to your development team and the currentproject. By default, CodeWizard is configured to suppress all violations that have an Informationalseverity and all violations in the Universal Coding Standard category, then unsuppress any violationsthat have a Severe Violation severity and unsuppress any enabled User items.

Suppressions are entered in the Suppressions Control Panel, which is accessible by clicking the Sup-press button in Insra when Insra is running and contains violations. For more information about sup-pressing and unsuppressing messages, see “Customizing Output With Suppressions” on page 19.

The Suppressions Tool BarMoving from left to right across the suppressions tool bar:

The Prev and Next arrows select the next higher or next lower suppression option, respectively.

The Up and Down arrows move the currently selected suppression option up or down in the order ofoptions. Because CodeWizard follows suppression options in the order they are listed (from top to bot-tom), they order in which they are listed affects the outcome of the suppressions.

The Delete button deletes the currently selected suppression option.

The Insert button inserts a new suppression option below the currently selected option. If you had aviolation message selected when you pressed the Suppress button on the Insra GUI, a suppressionoption for that particular violation will be inserted. Otherwise, the default suppression option (suppressall violation messages) will be inserted.

The Save button writes all the suppression options which have been marked as persistent (see below)into the indicated .psrc files (see below). These suppression options will be in effect the next time youuse CodeWizard.

The Help button provides context-sensitive help, which in this window means that clicking anywherewill bring up this file.

The Close button closes the suppression window.

45

Insra

Miscellaneous IssuesSuppression options are read from top to bottom when determining which messages will be displayed.

Kill ProcessWhen an active connection is selected, pressing the Kill button will stop the selected compilation orexecution.

Viewing Source FilesYou can view the corresponding source file and line number for a particular violation message by dou-ble clicking on any line of the stack trace displayed in the Message window. In most cases, the file andline number associated with a given message have been transmitted to Insra. If Insra is unable tolocate the source file, a dialog box will appear requesting that you indicate the correct source file.

Selecting an EditorIn addition to the location of the source file, Insra must also know the name of your editor, and (if avail-able) the command line syntax, in order to display the correct file and line from the original sourcecode.

Insra obtains information by reading the .psrc option:

insra.visual [editor_command]

This command may contain the special token %f and %l, which represent the file name and line num-ber, respectively.

The command will then be executed to lead the file into your editor. It is most important to include thefull path of any binary that lives in a location not pointed to by your PATH environment variable. If thevariable has not been set, vi will be used by default.

Some editors are not X applications and must be run in a terminal window. vi requires the followingcommand in order to lead the file successfully:

insra.visual xterm -e vi +%l %f

Other editors (for example, Emacs) do not require an external terminal program like xterm when config-ured for use as an X application. In this case, the command string should be similar to the following:

insra.visual emacs +%l %f

Note: Most implementations of vi and Emacs appear to be sensitive to the order of the line number andfile name command line arguments, requiring the line number to precede the file name.

Saving/Loading MessagesAll current messages can be saved to a file by selecting File> Save or File> Save As from the Insramenu bar. A dialog box allows you to select the destination directory and name of the report file. Reportfiles have the default extension rpt. After a report file name has been selected, subsequent File>Save selections save all current messages into the report file without prompting for a new filename. Apreviously saved report file can be loaded by selecting File> Load from the menu bar. A dialog boxthen allows you to select which report file to load.

The command insra.visual [editor command] specifies how Insra should call an editor to dis-play the line of source code causing the violation. Insra will match the %l token to the line number andthe %f token to the file name before executing the command. Setting this option with no commandstring disables source browsing from Insra. The default is: xterm -e vi +%l %f.

46

Insra

TroubleshootingInsra Does Not Start AutomaticallySymptom:

While compiling or running, your program seems to hang when output is directed to Insra and Insra isnot yet running.

Solution:

Run Insra by hand. Type

insra &

at the prompt, wait for the Insra window to appear, and then run or compile your program again. Outputshould now be sent to Insra.

Multiple Users of Insra On One MachineSymptom:

When more than one user is attempting to send message reports to Insra, messages are lost.

Solution:

Each invocation of Insra requires a unique port number. By default, Insra uses port 3255. If collisionsare experienced, e.g. multiple users are on one machine, set the .psrc option insra.port to a dif-ferent port above 1024. Ports less than 1024 are officially reserved for suid-root programs and shouldnot be used with Insra.

Source Browsing Is Not WorkingSymptom:

***Error while attempting to spawn browser execvp failed!

Solution:

Insra attempted to launch your editor to view the selected source file, but could not locate either xtermor your editor on your path. Please make sure that both of these applications are in directories that areon your path or that you call them with their complete pathnames.

HelpOnline help can be obtained by choosing Help from the Insra menu bar. Help contains the followingdrop–down menu:

• Overview: About Insra

• Insra toolbar

• Sending messages to Insra

• Suppressing Messages

• Viewing Source Files

• Troubleshooting

• About

Choosing anyone of these options opens an online help window with links about the chosen subject.These same online links are available by simply clicking the Help button on the tool bar.

47

Rules Enforced

48

Static Analysis RulesRules EnforcedCode violations are reported in terms of the "items" described in several popular Scott Meyers books,including Effective C++ and More Effective C++. Violations in these two categories are labeled "ecpp-<item number>" for Effective C++ violations and "mecpp-<item number>" for More Effective C++ viola-tions.

These items are supplemented by the article “Examining C++ Program Analyzers” written by Meyersand Martin Klaus and published in the February 1997 issue of Dr. Dobbs' Journal. Violations in this cat-egory are labeled "MK-<item number>" for Meyers-Klaus violations.

A fourth violation category includes industry accepted C++ coding rules known collectively as the Uni-versal Coding Standards. Violations in this category are labeled "ucs-<item number>" for ucs viola-tions.

Using the new RuleWizard feature, you can even create your own "custom" C or C++ items for ruleenforcement pertaining to your particular company, project, or personal coding needs. These customitems are included in the fifth violation category, User Items. Violations in this category are labeled“user-<item number> for user-customized violations.

Included within the User Item category is a set of built-in, modifiable “items” written by Parasoft basedupon specialized groups of standards. These items encompass 32-bit to 64-bit transition rules, Text-related rules, Metrics rules, Naming Conventions rules, and others. Violations of these built-in, modifi-able coding standards are labeled in the same manner as the custom user rules, “user-<item number>.See User Items for a more detailed description of these specialized items.

Each item, along with a general description, is accompanied by its category, the severity of the viola-tion, and whether it is enabled by default. Items reported have different levels of severity. The higherthe level of severity an item is assigned, the greater the chance that violating that error will result in abug. Each level is identified by its own unique abbreviation, as shown in the following table:

Each item category is described in depth within the following sections:

• Effective C++ Items

• More Effective C++ Items

• Built-in MISRA Guidelines

• Meyers-Klaus Items

• Universal Coding Standard Items

• User Items

• Ellemtel (Telecom Industry) Items

• User MISRA Guidelines

Severity Explanation

I Informational: least chance of resulting in a bug

PV Possible Violation

V Violation

PSV Possible Severe Violation

SV Severe Violation: greatest chance of resulting in a bug

Effective C++ Items

Effective C++ ItemsEffective C++ ItemsCategory Item Description Violation Enabled?

Shifting from C to C++

2 Prefer iostream.h to stdio.h. I N

3 Use new and delete instead of malloc and free.

V Y

Memory Management

5 Use the same form in corresponding calls to new and delete.

V Y

6 Call delete on pointer members in destruc-tors.

V Y

7 Check the return value of new. I N

8 Adhere to convention when writing new. V Y

9 Avoid hiding the global new. SV Y

10 Write delete if you write new. SV Y

Constructors, Destructors, and Assignment Operators

11 Define a copy constructor and assignment operator for classes with dynamically allo-cated memory.

V/ SV Y / Y

12 Prefer initialization to assignment in con-structors.

I N

13 List members in an initialization list in the order in which they are declared.

V Y

14 Make destructors virtual in base classes. SV Y

15 Have operator= return a reference to *this. SV Y

16 Assign to all data members in operator= PSV Y

17 Check for assignment to self in operator= PV Y

Classes and Functions: Design and Declaration

19 Differentiate among member functions, global functions, and friend functions.

V Y

20 Avoid data members in the public inter-face.

V Y

22 Pass and return objects by reference instead of by value.

V Y

23 Don't try to return a reference when you must return an object

PSV Y

25 Avoid overloading on a pointer and a numerical type.

V Y

49

Effective C++ Items

Item ecpp-2Prefer iostream.h to stdio.hThis rule finds instances of stdio.h functions (such as scanf/printf) and suggests changing them to iostream.h functions (such as operator>> and operator<< ). Errors are marked as violations of Item ecpp-02.

Reason for rule: iostream.h functions are type-safe and extensible.

Note: This item is suppressed by default.

Example/* * Item 2 - Prefer iostream.h to stdio.h */#include <stdio.h>

int main(){ printf("%s\n", "Hello World"); // ECPP item 2 violation return 0;}

Output[item02.C:8] Prefer iostream.h to stdio.hInformational: Effective C++ item 2

Classes and Functions: Implementation

29 Avoid returning "handles" to internal data from const member functions.

SV Y

30 Avoid member functions that return point-ers or references to members less acces-sible than themselves.

V Y

31 Never return a reference to a local object or a dereferenced pointer initialized by new within the function.

PSV / SV Y / Y

Inheritance and Object-Oriented

37 Never redefine an inherited nonvirtual function.

PV/V Y /Y

38 Never redefine an inherited default param-eter value.

I / V N /Y

39 Avoid casts down the inheritance hierar-chy.

I N

50

Effective C++ Items

Item ecpp-3Use new and delete instead of malloc and freeThis rule warns you if malloc and free are used in your code. Errors are marked as violations of Item ecpp-3.

Reason for rule: new and delete can handle constructors and destructors.

Example/* * Item 3 - Use new and delete instead of malloc and * free */

#include <malloc.h>int main(){ char *pc; pc = (char *)malloc(100); // ECPP item 3 violation free(pc); // ECPP item 3 violation return 0;}

Output[item03.C:10] Use new instead of mallocViolation: Effective C++ item 3

[item03.C:11] Use delete instead of freeViolation: Effective C++ Item 3

51

Effective C++ Items

Item ecpp-5Use the same form in corresponding calls to new and deleteThis rule checks calls to new and delete to make sure that they use the same form; it reports a viola-tion if you call new but forget to use [ ] when calling delete. Errors are marked as violations of Item ecpp-5.

Reason for rule: If you do not use the same form in corresponding calls to new and delete, an incor-rect number of destructors may be called.

Example/* * Item 5 - Use the same form in corresponding calls to * new and delete */class A{public: A() {}};

int main(){ A *a = new A[100]; delete a; // ECPP item 5 violation}

Output[item05.C:15] Use the same form in correspondingcalls to new and deleteViolation: Effective C++ item 5Found new[] with delete.

52

Effective C++ Items

Item ecpp-6Call delete on pointer members in destructorsThis rule warns you if it finds a pointer member that has no corresponding delete in the destructor. Errors are marked as violations of Item ecpp-6.

Reason for rule: Calling delete on pointer members in destructors prevents memory leaks now and as the code evolves in the future.

This severity level of this item is Violation (V).

Example/* * Item 6 - Call delete on pointer members in * destructors (SV,V). */class A{public: A() { cptr1=new char; cptr2=new char; } ~A() { // ECPP item 6 violation delete cptr1; delete vptr1; }

private: char *cptr1; void *vptr1; char *cptr2;};

int main(){ return 0;}

Output[item06.C:5] Call delete on pointer members in destructorsViolation: Effective C++ item 6Class A contains pointer members not obviously deleted in destructor:cptr2 ** allocated in constructor **

53

Effective C++ Items

Item ecpp-7Check the return value of newThis rule warns you if you do not check the return value of new. Errors are marked as violations of Item ecpp-7.

Reason for rule: In cases where new cannot allocate the requested memory, it will return 0.


Example/* * Item 7 - Check the return value of new */

int main(){ char *pc;

pc = new char[10*10*10]; // ECPP item 7 violation pc[0] = 'x'; delete [] pc; return 0;}

Output[item07.C:9] Check the return value of newInformational: Effective C++ item 7

54

Effective C++ Items

Item ecpp-8Adhere to convention when writing newWhen you write operator new, this rule checks to make sure that you are consistent with the default new. Errors are marked as violations of Item ecpp-8.

Reason for rule: If you do not adhere to convention when you write new, you may cause confusing inconsistencies for users of your new and delete operators.

Example/* * Item 8 - Adhere to convention when writing new */#include <stdlib.h>

class A{public: A() {} int* operator new(size-t size) // ECPP item 8 violation return (int *)(new int); };};


Output[item08.C:10] New should return void *Violation: Effective C++ item 8

55

Effective C++ Items

Item ecpp-9Avoid hiding the global newThis rule detects when the global new is hidden by an operator new. Errors are marked as violations of Item ecpp-9.

Reason for rule: If you hide the global new, normal new operator functionality will be unavailable to maintainers of your code.

Example/* * Item 9 - Avoid hiding the global new */

#include <stdlib.h>

void ErrorHandler() {};

class A{public: void* operator new(size-t size, void (*pehf)()) // ECPP item 9 violation { return new int[size]; } void operator delete(void *A) { delete A; }};

int main(){ A *a = new (ErrorHandler) A; return 0;}

Output[item09.C:12] Avoid hiding the global newSevere violation: Effective C++ item 9

56

Effective C++ Items

Item ecpp-10Write delete if you write newThis rule makes sure that if you write your own version of operator new, you also write a corre-sponding operator delete. Errors are marked as violations of Item ecpp-10.

Reason for rule: If you write delete when you write new, you ensure that new and delete share the same assumptions.

Note: Item user-212 is a customizable version of this rule.

Example/* * Item 10 - Write delete if you write new. */

#include <stdlib.h>class A{ // ECPP item 10 violationpublic: A() {} void* operator new(size-t size) { return new int[size]; }};int main(){ A *a = new A; return 0;}

Output[item10.C:11] Write delete if you write newSevere violation: Effective C++ item 10

57

Effective C++ Items

Item ecpp-11Define a copy constructor and assignment operator for classes with dynamically allocated memoryThis rule ensures that copy constructors and assignment operators have been defined in classes with dynamically allocated memory. Errors are marked as violations of Item ecpp-11.

Reason for rule: By defining a copy constructor and assignment operator, you achieve significant memory savings and increased speed.

ExampleViolations of Item 11 are reported as either Violation (V) or Severe (SV). Examples of both are provided here.

/* * Item 11 - Define a copy constructor and an * assignment operator for classes with dynamically * allocated memory (V). */

class A{public: class X {}; A() { // ECPP item 11 violation cptr1 = new char[100]; if (!cptr1) { throw X(); } } ~A() {}

private: char *cptr1; void *vptr1; char *cptr2;};


58

Effective C++ Items

/* * Item 11 - Define a copy constructor and an assignment * operator for classes with dynamically allocated * memory. (SV) */

class A{private: char *cptr1; void *vptr1; char *cptr2; public: A() {} ~A() { // ECPP item 11 violation delete cptr1; delete vptr1; delete cptr2; }};


Output[item11V.C:7] Define a copy constructor and operator=for classes with dynamically allocated memoryViolation: Effective C++ item 11Class A missing assignment operator and copy constructor.

[item11SV.C:7] Define a copy constructor and operator=for classes with dynamically allocated memorySevere violation: Effective C++ item 11Class A missing assignment operator and copy constructor.

59

Effective C++ Items

Item ecpp-12Prefer initialization to assignment in constructors This rule checks constructors to see if you are assigning data members when you should be initializing them. const and reference can only be initialized, never assigned. Errors are marked as violations of Item ecpp-12.

Reason for rule: If you use initialization instead of assignment, you will increase efficiency and call fewer member functions.

Exception: The only time you should use assignment instead of initialization for data members in a class is when you have a large number of data members of built-in types and you want them all to be initialized in the same way in each constructor.


Example /* * Item 12 - Prefer initialization to assignment in * constructors */

class A{public: A(int i, float j) { // ECPP item 12 violation _idata = i; _fdata = j; }

private: int _idata; float _fdata;};


Output [item12.C:9] Prefer initialization to assignmentin constructorsInformational: Effective C++ item 12

[item12.C:10] Prefer initialization to assignmentin constructorsInformational: Effective C++ item 12

60

Effective C++ Items

Item ecpp-13 List members in an initialization list in the order in which they are declaredThis rule checks initialization lists to make sure that members are listed in the same order there as they were when declared in the class. Errors are marked as violations of Item ecpp-13.

Reason for rule: Class members are initialized in the order of their declaration in the class, not by the order in which they are listed in a member initialization list.

Example/* * Item 13 - List members in an initialization list in * the order in which they are declared */

class A{public: // ECPP item 13 violation A(int i1, int i2, int i3) : idata3(i3), idata2(i2), idata1(i1) {}

private: int idata1, idata2, idata3;};


Output[item13.C:10] List members in an initialization listin the order in which they are declared Violation: Effective C++ item 13

61

Effective C++ Items

Item ecpp-14Make destructors virtual in base classesThis rule verifies that destructors in base classes are virtual. Errors are marked as violations of Item ecpp-14.

Reason for rule: Declaring the destructor virtual tells the compiler that it must examine the object being deleted to see where to start calling destructors.

Example/* * Item 14 - Make destructors virtual in base classes */

class Base{public: Base() {} ~Base() {} // ECPP item 14 violation};

class Derived: public Base{public: Derived() {}; ~Derived() {};};


Output[item14.C:6] Make destructors virtual in base classesSevere violation: Effective C++ item 14Class Base is a base class but does not have a virtualdestructor

62

Effective C++ Items

Item ecpp-15 Have operator= return a reference to *thisThis rule makes sure your assignment operators return a reference to their left-hand argument, *this. Errors are marked as violations of Item ecpp-15.

Reason for rule: Having operator= return a reference to *this protects you from not knowing where the temporary gets destroyed and allows you to declare the operator='s parameter as a refer-ence to const, which is safer than just declaring it to be a reference.

Example/* * Item 15 - Have operator= return a reference to *this */

class A{public: explicit A(int i = 0) : _i(i) {} void operator=(const A& a) // ECPP item 15 violation { if (&a == this) { return; } int _i = a._i; return; } private: int _i;};


Output[item15.C:9] Have operator= return a reference to*this Severe violation: Effective C++ item 15

63

Effective C++ Items

Item ecpp-16 Assign to all data members in operator=If you write operator=, this rule ensures that you assigned to every data member of your object. Errors are marked as violations of Item ecpp-16.

Reason for rule: Assigning to all data members in operator= allows you to take control of your assignments.

Example/* * Item 16 - Assign to all data members in operator= */

class A{public: A() {} A& operator=(const A&);

private: int _x, _y, _z;};

A& A::operator=(const A& a) // ECPP item 16 violation{ if (&a == this) { return *this; } _x = a._x; _y = a._y; return *this;}


Output[item16.C:16] Assign to all data members in operator=Possible severe violation: Effective C++ item 16Members not assigned: _z

64

Effective C++ Items

Item ecpp-17 Check for assignment to self in operator= This rule checks your code for aliasing in assignment operators. Errors are marked as violations of Item ecpp-17.

Reason for rule: Not checking for assignment to self in operator= can free resources that might be needed during the process of allocating new resources. Checking for assignment to self may also save you a lot of work that you would otherwise have to do to implement assignments.

Example/* * Item 17 - Check for assignment to self in operator= */

class A{public: A() {} A& operator=(A& a) // ECPP item 17 violation { _i = a._i; return *this; }

private: int _i;

}; int main(){ return 0;}

Output[item17.C:8] Check for assignment to self in operator=Possible violation: Effective C++ item 17 expected: if (&a == this) return *this;

65

Effective C++ Items

Item ecpp-19 Differentiate among member functions, global functions, and friend functionsThis rule checks declared functions to make sure they are proper for the class type used. Disallowed functions are marked as violations of Item ecpp-19.

Reason for rule: Differentiating among functions leads to more object-oriented code with behavior that is more intuitive to use and maintain.

Example/** Item 19 - Differentiate among member, global, and * friend functions.*/

class Rational{public: Rational(int _num = 0, int _den = 1); int numerator() const { return _num; } int denominator() const { return _den; } Rational operator*(const Rational& rhs) const; // ECPP item 19 violation private: int _num; int _den;};

Rational Rational::operator*(const Rational& rhs) const{ Rational temp(_num * rhs.numerator(), _den * rhs.denominator()); return temp;}


Output[item19.C:12] Differentiate among member functions,global functions and friend functionsViolation: Effective C++ item 19Function * should be global

66

Effective C++ Items

Item ecpp-20Avoid data members in the public interfaceThis rule warns you if data members are present in the public interface. Instead of making data mem-bers public, you should use functions. Errors are marked as violations of Item ecpp-20.

Reason for rule: Avoiding data members in the public interface provides more precise control over accessibility of data members, reduces confusion for callers, and enables functional abstraction (allow-ing the replacement of data members with computations without impacting users of the class). It also improves consistency, flexibility, and access-control.

Example/* * Item 20 - Avoid data members in the public interface */

class A{public: int _idata2; // ECPP item 20 violation int ReadData1(void) { return _idata1; } void WriteData1(int ival) { _idata1 = ival; }

private: int _idata1;};


Output [item20.C:6] Avoid data members in the public interfaceViolation: Effective C++ item 20Public data members for class A:_idata2

67

Effective C++ Items

Item ecpp-22 Pass and return objects by reference instead of by valueThis rule detects where an object has been passed by value instead of by reference. These errors are marked as violations of Item ecpp-22.

Reason for rule: Passing and returning objects by reference is more efficient than passing by value because no new objects are being created and because it avoids the "slicing problem."

Exception: There are situations in which you cannot pass an object by reference (see Item ecpp-23). There also may be a situation where the object is so small that it would be more efficient to pass by value instead of by reference.

Example/* * Item 22 - Pass and return objects by reference * instead of by value */

class A{public: A() {} A foo(const A a) // 2 ECPP item 22 violations { // passing variables into foo by value return a; // returning by value when it is not required }};


Output[item22.C:10] Pass objects by reference instead ofby valueViolation: Effective C++ item 22Parameter a of function foo passed by value

[item22.C:10] Return objects by reference instead of by valueViolation: Effective C++ item 22Function foo returns object by value

68

Effective C++ Items

Item ecpp-23Don't try to return a reference when you must return an objectThis rule detects when you return a reference where you are supposed to return an object. Errors are marked as violations of Item ecpp-23.

Reason for rule: Returning a reference instead of an object will result in corrupt data or a memory leak.

Example

/* * Item 23 - Don't try to return a reference when you * must return an object. */

class A{public: A(int num = 0, int den = 1) : _num(num), _den(den) {} int numerator() const { return _num; } int denominator() const { return _den; } private: int _num; int _den;};

// ECPP item 23 violationA& operator*(const A& lhs, const A& rhs) { A temp(lhs.numerator() * rhs.numerator(), lhs.denominator() * rhs.denominator()); return temp;}


Output[item23.C:19] Don't try to return a reference when youmust return an objectPossible severe violation: Effective C++ item 23Operator * should return an object

69

Effective C++ Items

Item ecpp-25Avoid overloading on a pointer and a numerical typeThis rule detects when you are overloading on a pointer and a numerical type. Errors are marked as violations of Item ecpp-25.

Reason for rule: Calling with an argument of zero will invoke the numerical type even though it is intu-itively ambiguous.

Example/* * Item 25 - Avoid overloading on a pointer and a * numerical type. */

class A{public: int func(char *ch) { char c=*ch; return 0; } int func(int i) // ECPP item 25 violation { int var=i; return 0; }};


Output[item25.C:8] Avoid overloading on a pointer and anumerical typeViolation: Effective C++ item 25 Function func overloaded at: [item25.C:8] [item25.C:13]

70

Effective C++ Items

Item ecpp-29Avoid returning "handles" to internal data from const member functionsThis rule detects when const member functions return “handles” to information that should be hidden. Errors are marked as violations of Item ecpp-29.

Reason for rule: If you return “handles” to internal data, you allow calling functions to modify variables that they should not have access to.

Example/* * Item 29 - Avoid returning "handles" to internal * data from const member functions */

class A{public: A() { ptr = 0; } operator char*() const { return ptr; } // ECPP item 29 violation

private: char *ptr;};


Output[item29.C:13] Avoid returning "handles" to internaldata from const member functionsSevere violation: Effective C++ item 29

71

Effective C++ Items

Item ecpp-30 Avoid member functions that return pointers or references to members less accessible than themselvesThis rule detects when you write member functions that give clients access to restricted members. Errors are marked as violations of Item ecpp-30.

Reason for rule: Members are made private or protected to restrict access to them, so it does not make sense to write functions that give random clients the ability to freely access restricted members.

Exception: Cases where performance constraints dictate that you write a member function that returns a reference or pointer to a less-accessible member. To avoid sacrificing private and protected access restrictions, return a pointer to or a reference to a const object (see Item ecpp-21).

Example /* * Item 30 - Avoid member functions that return * pointers or references to members less accessible * than themselves */

class A{public: int& GetA() { return _personalA; }; // ECPP item 30 violation

protected: int _personalA;};


Output [item30.C:9] Avoid member functions that returnpointers or references to members less accessiblethan themselvesViolation: Effective C++ item 30

72

Effective C++ Items

Item ecpp-31Never return a reference to a local object or a dereferenced pointer initialized by new within the functionThis rule detects when you return a reference to a local object or dereferenced pointer. Errors are marked as violations of Item ecpp-31.

Reason for rule: Returning a reference to a local object or a dereferenced pointer initialized by new within the function may cause a memory leak.

ExampleViolations of this item are reported as either Potentially Severe Violations (PSV) or Severe Violations (SV). Examples of both are provided here.

/* * Item 31 - Never return a reference to a local object * or a dereferenced pointer initialized by new * within the function */

class A{public: A(int xval, int yval) : _x(xval), _y(yval) {} friend A& operator+(const A& p1, const A& p2);

private: int _x, _y;};

A& operator+(const A& p1, const A& p2) // ECPP item 31 violation{ A *result = new A(p1._x + p2._x, p1._y + p2._y); return *result;}


73

Effective C++ Items

/* * Item 31 - Never return a reference to a local object or a * dereferenced pointer initialized by new within * the function */

class A{public: A(int xval, int yval) : _x(xval), _y(yval) {} friend A& operator+(const A& p1, const A& p2);

private: int _x, _y;};

A& operator+(const A& p1, const A& p2) // ECPP item 31 violation{ A result(p1._x + p2._x, p1._y + p2._y); return result;}


Output[item31PS.C:22] Never return a dereferenced localpointer initialized by new in this function scopePossible severe violation: Effective C++ item 31Dereferenced local pointer result returned.

[item31SV.C:22] Never return a reference to a localobjectSevere violation: Effective C++ item 31Reference to object result returned.

74

Effective C++ Items

Item ecpp-37Never redefine an inherited nonvirtual functionThis rule detects when you redefine an inherited nonvirtual function. These errors are violations of Item ecpp-37.

Reason for rule: Redefining an inherited nonvirtual function may cause objects to behave incorrectly.

Example Violations of this item are reported as either a Possible Violation (PV) or a Violation (V). Examples of both are provided here.

/* * Item 37 - Never redefine an inherited nonvirtual * function */

template<class T>class Base{public: void foo(T tval);};

template<class T>class Derived: public Base<T>{public: void foo(int tval); // ECPP item 37 violation};


75

Effective C++ Items

/* * Item 37 - Never redefine an inherited nonvirtual function */

class Base{public: void func(void) {};};

class Derived: public Base{public: void func(void) {}; // ECPP item 37 violation};


Output [item37PV.C:16] Never redefine an inherited nonvirtualfunctionPossible violation: Effective C++ item 37Redefinition of function foo in class DerivedFunction foo is inherited from class Base

[item37V.C:14] Never redefine an inherited nonvirtualfunctionViolation: Effective C++ item 37Redefinition of function func in class DerivedFunction func is inherited from class Base

76

Effective C++ Items

Item ecpp-38Never redefine an inherited default parameter valueThis rule detects where you redefine an inherited virtual function with a default parameter value. Errors are marked as violations of Item ecpp-38.

Reason for rule: As illustrated in the first example below, inherited nonvirtual functions should never be redefined. In the second example, virtual functions are dynamically bound and default parameter values are statically bound.

ExampleViolations of this item are reported as either Informational (I) or as a Violation (V). Examples of both are provided here.

/* * Item 38 - Never redefine an inherited default * parameter value */

template<class T>class Base{public: virtual void func(T i = -1111) {}};

template<class T>class Derived: public Base<T>{public: virtual void func(int i = 11) {} // ECPP item 38 violation};


77

Effective C++ Items

/* * Item 38 - Never redefine an inherited default parameter * value */

class Base{public: virtual int func(int i = -1111) { return i; }};

class Derived: public Base{public: virtual int func(int i = 11) { return i; } // ECPP item 38 violation};


Output [item38I.C:16] Never redefine an inherited default parameter valueInformational: Effective C++ item 38Function func in class Derived redefines default parameter i

[item38V.C:14] Never redefine an inherited default parameter valueViolation: Effective C++ item 38Function func in class Derived redefines default parameter i

78

Effective C++ Items

Item ecpp-39Avoid casts down the inheritance hierarchyThis rule detects casts from a base class pointer to a subclass pointer. Errors are marked as violations of Item ecpp-39.

Reason for rule: Allowing casts down the inheritance hierarchy leads to maintenance problems, and downcasting from a base class is always illegal. Note: This item is suppressed by default.

Example/* * Item 39 - Avoid casts down the inheritance hierarchy */

class Base {};

class Derived: public Base {};

int main(){ Base *pb; Derived *pd = (Derived *)pb; // ECPP item 39 violation return 0;}

Output[item39.C:12] Avoid casts down the inheritance hierarchyInformational: Effective C++ item 39Class Derived inherits from class Base

79

More Effective C++ Items

More Effective C++ ItemsMore Effective C++ ItemsCategory Item Description Violation Enabled?

Basics 2 Prefer C++ style casts V Y

Operators 5 Be wary of user-defined conversion functions I / V N / Y

6 Distinguish between prefix and postfix forms of increment and decrement operators

V Y

7 Never overload &&, | |, or , V Y

Efficiency 22 Consider using op= instead of stand-alone op V Y

24 Understand the costs of virtual functions, multi-ple inheritance, virtual base classes, and RTTI

V Y

Techniques 26 Limiting the number of objects in a class I N

80


Item mecpp-2Prefer C++ style castsThis rule detects C-style casts in your code. Errors are marked as violations of Item mecpp-02.

Reason for rule: C++ casts are more specific than C casts and are much easier to locate and read.

Example//// More Effective C++ Item 2//

class Base{public: Base(); virtual ~Base();};

class Derived : public Base{public: Derived(); ~Derived();};

int main(){ Base *pB; Derived *pD = (Derived *) pB; // MECPP item 2 violation. return 0;}

Output[ME-item02.C:23] Prefer C++-style castsViolation: More Effective C++ item 2

81


Item mecpp-5 Be wary of user-defined conversion functionsThis rule warns you when it finds user-defined conversion functions. Errors are marked as violations of Item mecpp-05.

Reason for rule: Using user-defined conversion functions may result in incorrect program behavior.

Note: The Information part of this rule is suppressed by default.

ExampleViolations are reported as either Information (I) or Violation (V). Examples of both are provided here.

//// More Effective C++ Item 5//

#include <stdlib.h>

class A{public: A(int i): _i(i) {} // MECPP item 5 violation virtual ~A() {} operator int() const // MECPP item 5 violation { return _i; } private: int _i;};

int main(){ int j = 10; A a(12); if (a < j) { // MECPP item 5 violation exit(1); } return 0;}

82


Output[ME-item05.C:8] Be wary of user-defined conversion functionsInformational: More Effective C++ item 5Constructor allowing conversion should be made explicit

[ME-item05.C:11] Be wary of user-defined conversion functionsViolation: More Effective C++ item 5User-defined conversion should be made explicit

[ME-item05.C:26] Be wary of user-defined conversion functionsViolation: More Effective C++ item 5Use of implicit cast should be made explicit

Item mecpp-6Distinguish between prefix and postfix forms of increment and decrement operatorsThis rule checks for a distinction between prefix and postfix forms of increment and decrement opera-tors. Failure to make this distinction in ++ and -- operators results in a violation of Item mecpp-06.

Reason for rule: Prefix and postfix forms return different types (prefix forms return a reference and postfix forms return a const object). Postfix operators should be implemented in terms of the prefix operator.


class A{ friend bool operator==(const A&, int);

public: explicit A(int i = 0): _i(i) {} ~A() {}

A& operator=(const A& a) { if (&a == this) { return *this; } _i = a._i; return *this; } A& operator=(int i) { _i = i; return *this; }

83


A& operator++() { ++_i; return *this; } const A operator++(int) { A temp = *this; ++_i; return temp; } private: int _i;};

bool operator==(const A& a, int i){ return (a._i == i);}

bool operator!=(const A& a, int i){ return (!(a == i));}

int main(){ A a;

for (a = 0; a != 10; a++) { // MECPP item 6 violation // Do something }

return 0;}

Output[ME-item06.C:57] Distinguish between prefix and postfix forms of increment and decrement Violation: More Effective C++ item 6Prefix form is recommended here

84


Item mecpp-7Never overload &&, | |, or ,This rule detects when you overload operator && , | | or ,. Errors are marked as violations of item mecpp-07.

Reason for rule: Overloading these operators changes the way the compiler reads the semantics of an expression, resulting in unpredictable program behavior.


class A{public: A(int i) : _i(i) {} ~A(); int value() { return _i; } private: int _i;};

operator&&(A& lhs, A& rhs) { // MECPP item 7 violation return lhs.value() && rhs.value();}


Output[ME-item07.C:17] Never overload &&, || or ,Violation: More Effective C++ item 7Function && is overloaded

85


Item mecpp-22Consider using op= instead of stand-alone opThis rule warns you whenever it finds stand-alone versions of operator. Errors are marked as viola-tions of Item mecpp-22.

Reason for rule: Assignment versions of operator are more efficient than stand-alone versions.


class A{public: A(int i) : _i(i) {} ~A(); int value() { return _i; } A operator+() {} // MECPP item 22 violation

private: int _i;};


Output[ME-item22.C:13] Consider using op= instead ofstand-alone opViolation: More Effective C++ item 22Operator + found, but no appropriate operator += found

86


Item mecpp-24Understand the costs of virtual functions, multiple inheritance, virtual base classes, and RTTIThis rule warns you when virtual functions, multiple-inheritance, virtual base classes, and RTTI are implemented inefficiently. Errors are marked as violations of Item mecpp- 24.

Reason for rule: Inefficient implementation may have noticeable effects on the size of objects and the speed at which member functions execute, significantly impacting performance.


class A{public: A(int i) : _i(i) {} virtual ~A() {} // MECPP item 24 violation int value() { return _i; } private: int _i;};


Output[ME-item24.C:9] Understand the costs of virtualfunctions ... Violation: More Effective C++ item 24Function ~A is both virtual and inline

87


Item mecpp-26Limiting the number of objects in a classThis rule detects the need to limit the number of objects in a class. Errors are marked as violations of Item mecpp-26.

Reason for rule: Limiting the number of objects in a class can reduce code complexity. Note: This item is suppressed by default.


class Base{public: class X {}; Base() { if(numObjects >= 1) throw X(); // constructor stuff here ++numObjects; } ~Base() { --numObjects; // destructor stuff here } private: static int numObjects;};


Output[item06.C:6] Limiting the number of objects of a classInformational: More Effective C++ item 26

88

Built-in MISRA Guidelines

Built-in MISRA ItemsBuilt-in MISRA GuidelinesCodeWizard 4.3 includes a suite of rules to enforce requirements imposed by the Motor Industry Soft-ware Reliability Association (MISRA). These requirements can be found in the MISRA document "Guidelines For The Use Of The C Language In Vehicle Based Software.”

Note: All statically enforceable rules from the MISRA Guidelines document were implemented. This section contains those MISRA rules implemented in CodeWizard as Built-in rules. Built-in MISRA rules are grouped under common prefix "misra.” For example "misra-20," "misra-112," and so on. The num-ber corresponds to a number given to the rule in the original MISRA document.

Important Cross ReferencesMISRA User RulesAdditional MISRA guidelines are implemented in CodeWizard as User rules. see “User MISRA Guide-lines” on page 344 for more information on the MISRA User rules included in CodeWizard.

Important! What is the difference between Built-in MISRA rules and User MISRA rules?

• User MISRA rules, like all rules in the User category (including the Ellemtel rules), can be cus-tomized using RuleWizard.

• Built-in MISRA rules, along with the Effective C++, More Effective C++, Meyer-Klaus, and Uni-versal Coding Standard rules, cannot be altered using RuleWizard.

Multiple File Static AnalysisSome of the rules will need symbol information collected across multiple source files. For example, to verify that given symbol has only one definition, CodeWizard can analyze information collected from multiple sources, and issue a violation if more than a single definition was detected. To facilitate static analysis preformed on multiple files, CodeWizard is now bundled with a new command line utility (cwmfs), that is capable of enforcing the new built-in MISRA-25, MISRA-26, and MISRA-27 rules.

This utility is described after the following rule descriptions. For more information, see “CodeWizard's cwmfs Utility” on page 127.

Additional MISRA RulesA few MISRA rules are not supported by CodeWizard, because they are not statically enforceable. These include MISRA-2, MISRA-15, and MISRA-116. For more information, see “A Note On Additional MISRA Rules” on page 127.

A Note On Severity LevelsThe MISRA Guidelines classify rules as "required" or "advisory." CodeWizard uses "Violation" and "Informational" severity levels for rules classified as "required" and "advisory," respectively.

Item Description Violation Enabled?

1 All code shall conform to ISO 9899 standard C, with no exten-sions permitted.

V Y

12 No identifier in one name space shall have the same spelling as an identifier in another name space.

I Y

20 All object and function identifiers shall be declared before use. V Y

25 An identifier with external linkage shall have exactly one external definition.

V Y

89


26 If objects or functions are declared more than once they shall have compatible declarations.

V Y

27 External objects should not be declared in more than one file. I Y

29 The use of a tag shall agree with its declaration. V Y

34 The operands of a logical && or || shall be primary expressions. V Y

47 No dependence should be placed on C's operator precedence rules in expressions.

I Y

53 All non-null statements shall have a side-effect. V Y

66 Only expressions concerned with loop control should appear within for statement.

I Y

71 Functions shall always have visible prototype at both the function definition and call.

V Y

77 The type of parameters passed to a function should be compati-ble with expected types defined in prototype.

V Y

78 The type of parameters passed to a function should be compati-ble with expected types defined in prototype.

V Y

94 A function-like macro shall not be 'called' without all of its argu-ments.

V Y

95 Arguments to a function-like macro shall not contain tokens that look like pre-processing directives.

V Y

97 Identifiers in pre-processor directives should be defined before use.

I Y

105 All the functions pointed to by a single pointer to function shall be identical in the number and type of parameters and the return type.

V Y

112 Avoid using bit fields of type signed int which are less than two bits long.

V Y

115 Standard library function names shall not be reused. V Y

117 The validity of values passed to library functions shall be checked.

V Y

118 Dynamic heap memory allocation shall not be used. V Y

90


MISRA-1All code shall conform to ISO 9899 standard C, with no extensions permitted. The MISRA Guidelines require the use of a "standardized structured language." The rule applies this to the C programming language. Any detected compiler extensions in the code will be flagged as viola-tions of this rule. Note: This rule is implemented as a built-in rule and it is active for C code only.

Example

/* misra001.c */

typedef void (*PTF)();

void foo() { void *ptr; PTF ptf = (PTF)ptr; /* violation - unable to cast from pointer to object to pointer to function */ }

#ifdef _MSC_VER /* MSVC specific part */ void __cdecl bar(); /* violation - uses msvc __cdecl keyword */ #endif /* _MSC_VER */

#ifdef __GNUC__ /* GNU gcc specific part */ struct Struct { char _c; int _buf[2] __attribute__ ((packed)); }; typedef int DeprecatedType1 __attribute__ ((deprecated)); DeprecatedType1 t1; #endif /* __GNUC__ */

Outputmisra001.c(8):All code shall conform to ISO 9899 standard C, with no extensions permitted.Violation: MISRA Guidelines item 1ISO 9899 nonconformance: invalid type conversion

misra001.c(14):All code shall conform to ISO 9899 standard C, with no extensions permitted.Violation: MISRA Guidelines item 1ISO 9899 nonconformance: incomplete type is not allowed

91


misra001.c(14):All code shall conform to ISO 9899 standard C, with no extensions permitted.Violation: MISRA Guidelines item 1ISO 9899 nonconformance: expected a ";"



MISRA-12No identifier in one name space shall have the same spelling as an identifier in another name space.The ISO 9899 C standard defines a number of different name spaces. Although it is technically possi-ble to use the same name in separate name spaces to represent completely different items, this prac-tice should not be used because it can cause confusion. Therefore, it is a violation to reuse names, even in separate name spaces. Note: This rule is implemented as a built-in rule and it is active for C code only.

Example /* misra012.c */

typedef struct Violation /* tags name space */ { int Violation; /* violation - name space of struct 'Violation' */ } Violation; /* violation - name space of identifiers */

Outputmisra012.c(5):No identifier in one name space shall have the same spelling as an identi-fier in another name space.Informational: MISRA Guidelines item 12Name Violation already used in other namespace.

misra012.c(6):No identifier in one name space shall have the same spelling as an identi-fier in another name space.Informational: MISRA Guidelines item 12Name Violation already used in other namespace.

92


MISRA-20All object and function identifiers shall be declared before use.MISRA rule 20 requires that all objects and functions must be declared before they are used. A decla-ration provides information to the compiler about the type of an object or function.

For example, if undeclared function is found, the compiler will have to make assumptions about the function prototype, and will not verify if actual parameter types match types specified in function decla-ration. This may lead to undefined behavior, which can result in hard-to-find errors at runtime. Note: This rule is implemented as a built-in rule and it is active for C code only.


void foo(); int global;

void goo() { int local;

foo(); undeclaredfoo(); /* violation */ local = global; local = undefinedglobal; /* violation */ }

Outputmisra020.c(11):All object and function shall be declared before useViolation: MISRA Guidelines item 20Undeclared function: undeclaredfoo is used

misra020.c(13):All object and function shall be declared before useViolation: MISRA Guidelines item 20Undeclared variable: undefinedglobal is used

93


MISRA-25An identifier with external linkage shall have exactly one external definition.This rule issues a violation if more than one definition of an identifier is found. Multiple definitions of a symbol can be a serious problem even if they are of the same type. Note: This rule is implemented as a built-in rule and it is active for C code only. It can be enforced using cwmfs command line tool bun-dled with CodeWizard.

Example /* misra25_1.c */ int a;

/* misra25_2.c */ int a;

Outputmisra25_1.c(5):An identifier with external linkage shall have exactly one external defini-tion.Violation: MISRA Guidelines item 25An identifier ìnt a' has more than one definition:misra25_1.c:2: ìnt a'misra25_2.c:2: ìnt a'

MISRA-26If objects or functions are declared more than once they shall have compatible declarations.This rule will report a violation if incompatible variable of function types are encountered. Note: This rule is implemented as a built-in rule and it is active for C code only. It can be enforced using cwmfs command line tool bundled with CodeWizard.

Example /* misra26_1.c */

static void foo (float t, int a) { }

int a() { extern int boo(float); return boo(1); }

void bar(float t, int i) {} void bar_decl(float t, int i);

94


int someFunc(int i);

extern int b(int i); int b(int i); int b(int i); int b(int i) { return i; }

int foo1(float a) { return 0; }

int someOtherFunc(int i); int someOtherFunc(char *);

/* misra26_2.c */

static void foo(float t) { }

int b() { extern int boo(int); return boo(0); }

void bar(float t) { } void bar_decl(float t); void* someFunc(const char *);

int foo1(int a) { return 0; }

Outputmisra26_1.c(23):If objects or functions are declared more than once they shall have compat-ible declarations.Violation: MISRA Guidelines item 26Symbol ìnt someOtherFunc(int)' have incompatible declaration:misra26_1.c:24: ìnt someOtherFunc(char *)'

misra26_1.c(16):If objects or functions are declared more than once they shall have compat-ible declarations.Violation: MISRA Guidelines item 26Symbol ìnt b(int)' have incompatible declaration: misra26_2.c:6: ìnt b()'


95




misra26_1.c(7):If objects or functions are declared more than once they shall have compat-ible declarations.Violation: MISRA Guidelines item 26Symbol ìnt boo(float)' have incompatible declaration: misra26_2.c:7: ìnt boo(int)'

misra26_1.c(11):If objects or functions are declared more than once they shall have compat-ible declarations.Violation: MISRA Guidelines item 26Symbol `void bar(float, int)' have incompatible declaration: misra26_2.c:11: `void bar(float)'

misra26_1.c(12):If objects or functions are declared more than once they shall have compat-ible declarations.Violation: MISRA Guidelines item 26Symbol `void bar_decl(float, int)' have incompatible declaration: misra26_2.c:12: `void bar_decl(float)'

misra26_1.c(14):If objects or functions are declared more than once they shall have compat-ible declarations.Violation: MISRA Guidelines item 26Symbol ìnt someFunc(int)' have incompatible declaration: misra26_2.c:13: `void * someFunc(const char *)'

misra26_1.c(21):If objects or functions are declared more than once they shall have compat-ible declarations.Violation: MISRA Guidelines item 26Symbol ìnt foo1(float)' have incompatible declaration: misra26_2.c:15: ìnt foo1(int)'

96


MISRA-27External objects should not be declared in more than one file.External objects should be declared in header files which are then included in all those source files which use these objects. This rule will inform about multiple declarations of symbols. Note: This rule is implemented as a built-in rule and it is active for C code only. It can be enforced using cwmfs com-mand line tool bundled with CodeWizard.

Example /* misra027.h */

extern int a;

/* misra027_1.c */

#include "misra027.h" int a;

/* misra027_2.c */

extern int a;

Outputmisra027.h(3):External object should not be declared in more than one file.Informational: MISRA Guidelines item 27Symbol `int a' is also declared in: misra027_2.c:3

97


MISRA-29The use of a tag shall agree with its declaration.This rule will report violation when tag initializers do not agree with the structure declared for that tag. Note: This rule is implemented as a built-in rule and it is active for C code only.


struct tagSTRUCT { int _x; };

/* OK - initialiser of type int matches type of field _x: */ struct tagSTRUCT s = { 123 };

/* violation - 'char *' initialiser does not match type of field _x: */ struct tagSTRUCT t = { "abc" };

Outputmisra029.c(12):The use of a tag shall agree with its declaration.Violation: MISRA Guidelines item 29Usage of tag STRUCT does not agree with the declaration.

98


MISRA-34The operands of a logical && or || shall be primary expressions.This rule requires that only primary expressions appear as operands of logical && and || operators. Effectively, the rule requires that if an operand is other than a single identifier or constant or string lit-eral, then it must be parenthesized. Complying with this rule both improves readability of code and ensures that the code behaves as intended. Note: This rule is implemented as a built-in rule and it is active for C code only.


int bar();

enum E { AA, BB, CC };

void foo(int i, int j) { if (i == 1 && (j == 2)) { /* violation */ }

if (i == 1 || j == 2 || j == 3) { /* 2 violations */ } if (i == 1 && j == 2 || j == 3) { /* 2 violations */ }

if (12 || i || "abc" || (i + j)) { /* OK */ }

if (bar() && (j == 1)) { /* violation */ } if ((bar()) && (j == 1)) { /* OK */ }

if (i && j) { /* OK */ }

if (i << 2 || j >> 3) { /* violation */ }

while (i != AA || j != BB) { /* violation */ i = AA; }

j = i == AA || j==i; /* violation */ }

99


Outputmisra034.c(10):The operands of a logical && or || shall be primary expressions.Violation: MISRA Guidelines item 34The left operand of logical operator AND is not a primary expression.

misra034.c(13):The operands of a logical && or || shall be primary expressions.Violation: MISRA Guidelines item 34The right operand of logical operator OR is not a primary expression.

misra034.c(13):The operands of a logical && or || shall be primary expressions.Violation: MISRA Guidelines item 34Operands of logical operator OR are not primary expressions.

misra034.c(15):The operands of a logical && or || shall be primary expressions.Violation: MISRA Guidelines item 34The right operand of logical operator OR is not a primary expression.

misra034.c(15):The operands of a logical && or || shall be primary expressions.Violation: MISRA Guidelines item 34Operands of logical operator AND are not primary expressions.

misra034.c(21):The operands of a logical && or || shall be primary expressions.Violation: MISRA Guidelines item 34The left operand of logical operator AND is not a primary expression.




100


MISRA-47No dependence should be placed on C's operator precedence rules in expressions.This rule encourages to use parentheses not only to override the default operator precedence, but also to emphasize it. Complying with this rule both improves readability of code and ensures that the code behaves as intended. Note: This rule is implemented as a built-in rule and it is active for C code only.


void foo(int i, int j) { int a, b, c, d, x; a = b = c = d = x = 1;

x = (3 * a) + (b / c); /* OK */ x = 3 * a + b / c; /* violation */

x = a + b - c + d; /* OK */ x = ((a + b) - c) + d; /* OK */ x = a + b - (c + d); /* OK */ x = (a + b) - (c + d); /* OK */

x = a + b, c * d; /* OK */ x = 3 * a & b / c; /* violation */ x = 3 % a >> b + c; /* violation */ x = 3 ^ a | b >= c; /* violation */

x = 3 ^ a || b >= c && d >> 1; /* 2 violations */

x = (3 ^ a) || (b >= c) && d >> 1; /* 2 violations */ x = (3 ^ a) && (b >= c) || d >> 1; /* violation */ x = ((3 ^ a) && (b >= c)) || d >> 1; /* violation */ x = ((3 ^ a) || (b >= c)) && d >> 1; /* violation */ }

void bar(int i, char **arr) { if (i > 1 && arr[1][0] == '-') { /* violation */ } }

101


Outputmisra047.c(9):Do not depend on C's operator precedence.Informational: MISRA Guidelines item 47Emphasize precedence by using parentheses around operand(s) of addition operator (+).

misra047.c(17):Do not depend on C's operator precedence.Informational: MISRA Guidelines item 47Emphasize precedence by using parentheses around operand(s) of bitwise AND operator (&).

misra047.c(18):Do not depend on C's operator precedence.Informational: MISRA Guidelines item 47Emphasize precedence by using parentheses around operand(s) of right shift operator (<<).

misra047.c(19):Do not depend on C's operator precedence.Informational: MISRA Guidelines item 47Emphasize precedence by using parentheses around operand(s) of bitwise OR operator (|).

misra047.c(21):Do not depend on C's operator precedence.Informational: MISRA Guidelines item 47Emphasize precedence by using parentheses around operand(s) of logical OR operator (||).

misra047.c(21):Do not depend on C's operator precedence.Informational: MISRA Guidelines item 47Emphasize precedence by using parentheses around operand(s) of logical AND operator (&&).



102






MISRA-53All non-null statements shall have a side-effect.As defined by ISO/IEC 9899:1999 standard, a side effect is defined as: "Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment."

A null statement is, according to the standard, a statement "consisting of just a semicolon." This rule will report a violation message each time a non-null statement (i.e. statement consisting of just a semi-colon) is detected with no side-effects. For example, if an expression evaluation result is not used, because a programmer forgot to use assignment operator to store the value, or because he acciden-tally wrote "==" instead of "=", the statement is considered not to have a side effect. Such program-ming errors are potentially disastrous.

This rule will also report violation if an empty block statement is detected, since such a statement has no effect. Empty function body is not considered as violating this rule. For purposes of this rule any function call is considered as having side effects, even if no variable is modified as a result of the func-tion call. Note: This rule is implemented as a built-in rule and it is active for C code only.

103



struct tagStruct { int _iField; char * _p; };

volatile struct tagStruct _SSS;

int bar();

void foo() { int i = 0; volatile int j = 0; struct tagStruct s, *ps;

/* with side effects: */ i = i + 3; /* OK - assignment */ i <<= 3; /* OK - assignment */ bar(); /* OK - function call */ j; /* OK - volatile variable */ _SSS._p; /* OK - volatile variable */

/* no side effects: */ i + 3; /* violation - result not used */ 3; /* violation - result not used */ i; /* violation - result not used */ i + bar(); /* violation - result not used */ switch (i) { } /* violation - empty block - no side-effect */ ps->_p + s._iField; /* violation - result not used */ ps->_iField << s._iField; /* violation - result not used */ *(ps->_p); /* violation - result not used */

/* null statement - OK */ ;

{ /* violation - empty block - no side-effect */ }

} /* foo() */

Outputmisra053.c(27):All non-null statements shall have a side-effect.Violation: MISRA Guidelines item 53Statement with no side-effects detected.

104


misra053.c(28):All non-null statements shall have a side-effect.Violation: MISRA Guidelines item 53Statement with no side-effects detected.



misra053.c(31):All non-null statements shall have a side-effect.Violation: MISRA Guidelines item 53An empty block statement has no side-effect.




misra053.c(39):All non-null statements shall have a side-effect.Violation: MISRA Guidelines item 53An empty block statement has no side-effect.

105


MISRA-66Only expressions concerned with loop control should appear within for statement.This rule analyzes for statements to find any variables that are used within initialization or update sec-tions of the statements, but do not seem to be concerned with loop control. Often, variables are initial-ized within the for statement even though they have nothing to do with stop condition of the loop. In extreme cases entire for statement blocks can be moved into the for statement, which makes the code both error-prone and hard to read. Complying with this rule leads to safer and more readable code. Note: This rule is implemented as a built-in rule and it is active for C code only.


int bar(int i);

void foo() { int i, j, k, l;

i = j = k = l = 0;

for (i = 0; i < 10; ++ i) { /* OK */ }

for (i = 0; i < 10; ++ i, ++j) { /* violation - j */ } for (i = 0, j = 1; i < 10; ++ i) { /* violation - j */ } for (i = 0, j = 1; i < 10; ++ i, ++ j) { /* violation - j */ } for (i = 0, j = 1; i+j < 10; ++ i, ++ j) { /* OK */ }

for (i = 0; i < 10; ++ i, bar(j)) { /* violation - j */ }

for (i = 0; i < 10; ++ i, bar(j), ++k, l >> 1) { /* violation - j, k, l */ }

for (i = j; i < k; ++ i) { /* OK */ } for (i = j, l = j; i < k; ++ i) { /* violation - l */ } for (i++, l++, j += i; i < k; ++ i) { /* violation - j, l */ } for (bar(j), l + 3; i < k; ++ i) { /* violation - j, l */ } }

106


Outputmisra066.c(14):Only expressions concerned with loop control should appear within a for statement.Informational: MISRA Guidelines item 66The following variables do not seem to be concerned with for loop control: j

misra066.c(16):Only expressions concerned with loop control should appear within a for statement.Informational: MISRA Guidelines item 66The following variables do not seem to be concerned with for loop control: j



misra066.c(26):Only expressions concerned with loop control should appear within a for statement.Informational: MISRA Guidelines item 66The following variables do not seem to be concerned with for loop control: j, k, l

misra066.c(31):Only expressions concerned with loop control should appear within a for statement.Informational: MISRA Guidelines item 66The following variables do not seem to be concerned with for loop control: l

misra066.c(33):Only expressions concerned with loop control should appear within a for statement.Informational: MISRA Guidelines item 66The following variables do not seem to be concerned with for loop control: l, j


107


MISRA-71Functions shall always have visible prototype at both the function definition and call.According to the ISO/IEC 9989:1999 C standard, a function prototype is a declaration of a function that declares the types of its parameters. MISRA rule 71 requires that any function must be declared before its is called or defined. This means that function prototype must appear before the definition or call. The example below illustrates cases verified by this rule. Note: This rule is implemented as a built-in rule and it is active for C code only.


/* case 1 - both function call and definition have visible prototype */ void case1foo(void); /* prototype */ void case1goo(void); /* prototype */ void case1goo() { /* OK */ case1foo(); /* OK */ }

/* case 2 - definition without prototype */ void case2goo() { /* violation */ }

/* case 3 - call without prototype */ void case3goo(void); void case3goo(void) { case3foo(); /* violation */ }

/* case 4 - definition without prototype although function declared */ void case4goo(); /* this is not a prototype (no arguments declared) */ void case4goo() { /* violation */ }

/* case 5 - call without prototype although function declared */ void case5foo(); void case5goo(void); void case5goo() { case5foo(); /* violation */ }

/* case 6 - definition w prototype declared after function definition */ void case6goo() { /* violation */ } void case6goo(void);

108


/* case 7 - call with prototype declared after function call */ void case7goo(void); void case7goo(void) { case7foo(); /* violation */ } void case7foo(void);

Outputmisra071.c(13):Functions shall always have visible prototype at both the function defini-tion and callViolation: MISRA Guidelines item 71Function case2goo has no visible prototype at the point of definition

misra071.c(20):Functions shall always have visible prototype at both the function defini-tion and callViolation: MISRA Guidelines item 71Function case3foo has no visible prototype at the point of call

misra071.c(26):Functions shall always have visible prototype at both the function defini-tion and callViolation: MISRA Guidelines item 71Function case4goo has no visible prototype at the point of definition


misra071.c(39):Functions shall always have visible prototype at both the function defini-tion and callViolation: MISRA Guidelines item 71Function case6goo has no visible prototype at the point of definition


109


MISRA-77The type of parameters passed to a function should be compatible with expected types defined in prototype.According to the ISO/IEC 9989:1999 C standard, a function prototype is a declaration of a function that declares the types of its parameters. MISRA rule 77 requires that types of arguments passed to a function match the types from the prototype, ignoring any const or volatile qualifiers. The exam-ple below illustrates cases verified by this rule. Note: This rule is implemented as a built-in rule and it is active for C code only.


/* case 1 - correct - unqualified types from prototype and call match */ void case1ifoo(const int, volatile int, const volatile int, int); void case1goo(void); void case1goo() { int i = 10; const int ci = 20; volatile int vi = 20; const volatile int cvi = 20; case1ifoo(10, 10, 10, 10); /* OK */ case1ifoo(i, i, i, i); /* OK */ case1ifoo(ci, ci, ci, ci); /* OK */ case1ifoo(vi, vi, vi, vi); /* OK */ case1ifoo(cvi, cvi, cvi, cvi); /* OK */ }

/* case 2 - unqualified types from prototype and call do not match */ void case2ifoo(const int, volatile int, const volatile int, int); void case2goo(void); void case2goo() { float f = 10; const float cf = 20; volatile float vf = 20; const volatile float cvf = 20; case2ifoo('a', 10., 0.1, "text"); /* 4 violations */ case2ifoo(f, cf, vf, cvf); /* 4 violations */ }

110


/* case 3 - a case with elipsis */ void case3ifoo(int, ...); void case3goo(void); void case3goo() { case3ifoo(10, 10); /* OK */ case3ifoo(10.1, 11); /* violation */ case3ifoo(10, 10.1); /* OK */ case3ifoo(10, 10, 10); /* OK */ case3ifoo(10); /* OK */ }

/* case 4 - a case with void */ void case4foo(void); void case4goo(void); void case4goo(void) { case4foo(); /* OK */ case4foo(10); /* OK */ }

/* case 5 - a case with structs */ typedef struct _AAA { int i; int j; } AAA; typedef struct _BBB { float f; float g; } BBB;

void case5Afoo(AAA); void case5Bfoo(BBB); void case5goo(void); void case5goo() { AAA a; const AAA ca; volatile AAA va; const volatile AAA cva; case5Afoo(a); /* OK */ case5Afoo(ca); /* OK */ case5Afoo(va); /* OK */ case5Afoo(cva); /* OK */ case5Bfoo(a); /* violation */ case5Bfoo(ca); /* violation */ case5Bfoo(va); /* violation */ case5Bfoo(cva); /* violation */ case5Afoo(10); /* violation */ }

111


Outputmisra077.c(32):The type of parameters passed to a function should be compatible with the expected types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case2ifooParameter number: 1Passed parameter type: charExpected parameter type: const int

misra077.c(32):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case2ifooParameter number: 2Passed parameter type: doubleExpected parameter type: volatile int

misra077.c(32):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case2ifooParameter number: 3Passed parameter type: doubleExpected parameter type: const volatile int

misra077.c(32):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case2ifooParameter number: 4

misra077.c(33):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case2ifooParameter number: 1Passed parameter type: floatExpected parameter type: const int

misra077.c(33):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case2ifooParameter number: 2Passed parameter type: const floatExpected parameter type: volatile int

112


misra077.c(33):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case2ifooParameter number: 3Passed parameter type: volatile floatExpected parameter type: const volatile int

misra077.c(33):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case2ifooParameter number: 4Passed parameter type: const volatile floatExpected parameter type: int

misra077.c(42):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case3ifooParameter number: 1Passed parameter type: doubleExpected parameter type: int

misra077.c(81):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case5BfooParameter number: 1Passed parameter type: _AAAExpected parameter type: _BBB


113




misra077.c(85):The type of parameters passed to a function should be compatible with expected the types defined in the prototypeViolation: MISRA Guidelines item 77Inconsistent parameter type during calling function: case5AfooParameter number: 1Passed parameter type: intExpected parameter type: _AAA

MISRA-78The type of parameters passed to a function should be compatible with expected types defined in prototype.According to the ISO/IEC 9989:1999 C standard, a function prototype is a declaration of a function that declares the types of its parameters. MISRA rule 78 requires that the number of arguments passed to a function match the number declared in the prototype. The example below illustrates various cases verified by this rule. Note: This rule is implemented as a built-in rule and it is active for C code only.

Example

/* misra078.c */

void iiifoo(int, int, int); void iiefoo(int, int, ...); void vfoo(void);

void goo() { iiifoo(6, 6); /* violation */

iiifoo(6, 6, 6); /* OK */

iiifoo(6, 6, 6, 6); /* violation */

114


iiefoo(6, 6); /* violation */

iiefoo(6, 6, 6); /* OK */

iiefoo(6, 6, 6, 6); /* OK */

vfoo(); /* OK */

vfoo(7); /* violation */ }

Outputmisra078.c(9):The number of parameters passed to a function shall match the function pro-totypeViolation: MISRA Guidelines item 78Inconsistent number of parameters during calling function: iiifooPassed parameters count: 2Expected parameters count: 3

misra078.c(13):The number of parameters passed to a function shall match the function pro-totypeViolation: MISRA Guidelines item 78Inconsistent number of parameters during calling function: iiifooPassed parameters count: 4Expected parameters count: 3

misra078.c(15):The number of parameters passed to a function shall match the function pro-totypeViolation: MISRA Guidelines item 78Inconsistent number of parameters during calling function: iiefooPassed parameters count: 2Expected parameters count: 3+

misra078.c(23):The number of parameters passed to a function shall match the function pro-totypeViolation: MISRA Guidelines item 78Inconsistent number of parameters during calling function: vfooPassed parameters count: 1Expected parameters count: 0

115


MISRA-94A function-like macro shall not be 'called' without all of its arguments.If one or more arguments to the function-like macro are not supplied when it is called, then the behavior is undefined. Many pre-processors will issue an error, but in some cases no error is reported, which can lead to hard-to-detect errors at runtime. Note: This rule is implemented as a built-in rule and it is active for C code only.


#define MACRO1(x) x = 1 #define MACRO2(x, y) x = y = 1 #define MACRO3(x, y, z) x = y = z = 1

void violation(void) { int i; MACRO1(i); /* OK */ MACRO2(i); /* violation */ MACRO3(i, i, i); /* OK */ }

Outputmisra094.c(12):A function-like macro shall not be 'called' without all of its arguments.Violation: MISRA Guidelines item 94Function-like macro MACRO2 used without all of its arguments.

116


MISRA-95Arguments to a function-like macro shall not contain tokens that look like pre-processing directives.If any of the arguments to the function-like macro look like pre-processor directives, the behavior when macro substitution is made can be unpredictable. Note: This rule is implemented as a built-in rule and it is active for C code only.


#define MACRO1(x) #define MACRO2(x, y)

void violation(void) { int i = 0; MACRO1(i); /* OK */ MACRO1(#foo); /* violation */ MACRO2(i, i); /* OK */ MACRO2(i, #foo); /* violation */ MACRO2(i, "#foo"); /* violation */ }

Outputmisra095.c(11):Arguments to a function-like macro shall not contain tokens that look like pre-processing directives.Violation: MISRA Guidelines item 95Function-like macro MACRO1 called with argument that looks like pre-process-ing directive.

misra095.c(13):Arguments to a function-like macro shall not contain tokens that look like pre-processing directives.Violation: MISRA Guidelines item 95Function-like macro MACRO2 called with argument that looks like pre-process-ing directive.

misra095.c(14):Arguments to a function-like macro shall not contain tokens that look like pre-processing directives.Violation: MISRA Guidelines item 95Function-like macro MACRO2 called with argument that looks like pre-process-ing directive.

117


MISRA-97Identifiers in pre-processor directives should be defined before use.This rule requires that all identifiers used in pre-processor directives are defined. Otherwise the prepro-cessor will often silently assume a value of zero for that identifier without issuing any warnings, which can often lead to hard-to-detect errors. Note: This rule is implemented as a built-in rule and it is active for C code only.


#if X /* violation - X undefined at this point */ #endif

#if Y /* violation - Y undefined at this point */ #endif

#if X + Y /* violation - X and Y undefined at this point */ #endif

#define X 1

#if X /* OK */ #endif

#ifdef Y #if Y /* OK - check is done in the #ifdef above */ #endif #endif

Outputmisra097.c(3):Identifiers in pre-processor directives should be defined before use.Informational: MISRA Guidelines item 97Identifier X is undefined at this point.

misra097.c(7):Identifiers in pre-processor directives should be defined before use.Informational: MISRA Guidelines item 97Identifier Y is undefined at this point.

misra097.c(11):Identifiers in pre-processor directives should be defined before use.Informational: MISRA Guidelines item 97Identifier X is undefined at this point.

118


misra097.c(11):Identifiers in pre-processor directives should be defined before use.Informational: MISRA Guidelines item 97Identifier Y is undefined at this point.

MISRA-105All the functions pointed to by a single pointer to function shall be identical in the number and type of parameters and the return type.Pointers to functions can easily violate type integrity, so all pointed-to functions should be of identical type. Note: This rule is implemented as a built-in rule and it is active for C code only.


typedef int(*PTF)(int, char*); typedef void(*PTF2)(void);

int foo(int i, char* c){ return 0;}

void bar(void) { }

void test(void) { PTF p; void *purePtr = 0; char *charPtr = 0; PTF2 q = bar; /* OK */ PTF arrOK[] = { foo, &foo }; /* OK */ PTF arrV[] = { foo, (PTF)&bar }; /* violation */

p = &foo; /* OK */ p = (PTF) bar; /* violation */

p = (PTF) q; /* violation */

p = purePtr; /* violation */ p = (PTF) purePtr; /* OK */

p = (PTF)charPtr; /* violation */ }

119


Outputmisra105.c(19):All the functions pointed to by a single pointer to function shall be iden-tical in the number and type of parameters and the return type.Violation: MISRA Guidelines item 105Type of assignee doesn't match type of expression being assigned.

misra105.c(22):All the functions pointed to by a single pointer to function shall be iden-tical in the number and type of parameters and the return type.Violation: MISRA Guidelines item 105Type of assignee doesn't match type of expression being assigned.




120


MISRA-112Avoid using bit fields of type signed int which are less than two bits long.This rule enforces that all fields of type 'signed int' are at least 2 bits 'long'. Note that the rule does not trigger for plain 'int' bit fields, because it is assumed that the code also complies with MISRA rule 111. The MISRA rule 111 considers it a violation not to explicitly specify whether bit field is signed or unsigned. Note: This rule is implemented as a built-in rule and it is active for C code only.


typedef signed int SINT; typedef SINT SINT2;

struct Misra112 { signed int si01:1; /* violation */ signed int si02:2; signed int si03:3; SINT si11:1; /* violation */ SINT si12:2; SINT si13:3; SINT2 si21:1; /* violation */ SINT2 si22:2; SINT2 si23:3; int i1:1; int i2:2; int i3:3; unsigned int ui1:1; unsigned int ui2:2; unsigned int ui3:3; }; typedef union { struct Nested { signed int nsi01:1; /* violation */ signed int nsi02:2; } nested; signed int usi01:1; /* violation */ signed int usi02:2; } Misra112;

void foo() { struct Internal { signed int Isi01:2; signed int Isi02:1; /* violation */ }; }

121


Outputmisra112.c(7):Avoid using bit fields of type signed int which are less than two bits longViolation: MISRA Guidelines item 112si01 is declared as variable which type is signed int and has bits size: 1

misra112.c(10):Avoid using bit fields of type signed int which are less than two bits longViolation: MISRA Guidelines item 112si11 is declared as variable which type is signed int and has bits size: 1

misra112.c(13):Avoid using bit fields of type signed int which are less than two bits longViolation: MISRA Guidelines item 112si21 is declared as variable which type is signed int and has bits size: 1

misra112.c(26):Avoid using bit fields of type signed int which are less than two bits longViolation: MISRA Guidelines item 112nsi01 is declared as variable which type is signed int and has bits size: 1

misra112.c(30):Avoid using bit fields of type signed int which are less than two bits longViolation: MISRA Guidelines item 112usi01 is declared as variable which type is signed int and has bits size: 1

misra112.c(37):Avoid using bit fields of type signed int which are less than two bits longViolation: MISRA Guidelines item 112Isi02 is declared as variable which type is signed int and has bits size: 1

122


MISRA-115Standard library function names shall not be reused.This rule requires that any new versions of standard functions are given names different than the origi-nal functions. This is to avoid confusion as to whether a standard library function is being used or whether a modified version of that function is being used.

This rule will report violation for the redefinition of functions listed in Annex B of the ISO/IEC 9899:1999 standard. It will also report any function definitions whose names conflict with any of function macros defined in the standard (see the example below). Note: This rule is implemented as a built-in rule and it is active for C code only.


double sqrt(double); /* OK - just declared */

double sqrt(double arg) /* violation - redefined */ { return (arg); }

void strpbrk(double arg) { } /* violation - redefined */

/* macro redefined as function */ void offsetof(double arg) { } /* violation - std. macro name */

void foo() /* OK - user function */ { sqrt(123.0); /* OK - std. C function call */ }

Output[misra115.c][line:6] Standard library function names shall not be reused.Violation: MISRA Guidelines item 115Detected redefinition of standard C library function sqrt.

[misra115.c][line:11] Standard library function names shall not be reused.Violation: MISRA Guidelines item 115Detected redefinition of standard C library function strpbrk.

[misra115.c][line:14] Standard library function names shall not be reused.Violation: MISRA Guidelines item 115Detected redefinition of standard C library function offsetof.

123


MISRA-117The validity of values passed to library functions shall be checked.Since many of the standard C library functions are not required to check the validity of parameters passed to them. Even where checking is required by the standard, there is no guarantee that ade-quate checking will take place. Therefore the programmer shall provide appropriate checks of input values.

Implementation of this rule will search function body prior to the library function call to see if its argu-ments are used within conditional statement conditions, or passed to any functions. Such use will be considered as argument validation necessary to comply with this rule. Note: This rule is implemented as a built-in rule and it is active for C code only.


void* memcpy(void *, void*, int n);

void test(void *v) { }

int getSomeIntValue() { return 0; }

void foo() { void *p, *q; int n; memcpy(p, q, n); /* Violation - complain about p, q and n */ test(q); /* consider it a validation of q */ memcpy(p, q, n); /* Violation - complain about p, and n */ switch (n) { /* consider it a validation of n */ case 0: break; } if (p == 0) { /* consider it a validation of p */ }

memcpy(p, q, n); /* OK */ /* Violation - complain only about getSomeIntValue call */ memcpy(p, q, getSomeIntValue()); }

124


Outputmisra117.c(17):The validity of values passed to library functions shall be checked.Violation: MISRA Guidelines item 117Value p passed to library function without being checked.

misra117.c(17):The validity of values passed to library functions shall be checked.Violation: MISRA Guidelines item 117Value q passed to library function without being checked.

misra117.c(17):The validity of values passed to library functions shall be checked.Violation: MISRA Guidelines item 117Value n passed to library function without being checked.

misra117.c(34):The validity of values passed to library functions shall be checked.Violation: MISRA Guidelines item 117Result of getSomeIntValue passed to library function without being checked.

MISRA-118Dynamic heap memory allocation shall not be used.The rule will verify if any of the following standard C functions are used: malloc, realloc, calloc, free. In a call to any of these functions is detected, CodeWizard will report this as a violation. Note: This rule is implemented as a built-in rule and it is active for C code only.


#include <stdlib.h>

int main() { char * p = 0;

p = (char *) malloc(128); /* violation */ p = (char *) realloc(p, 256); /* violation */

free(p); /* violation */ p = 0;

p = (char *) calloc(128, 1); /* violation */ free(p); /* violation */ return (0); }

125


Outputmisra118.c(9):Dynamic heap memory allocation shall not be used.Violation: MISRA Guidelines item 118Detected use of dynamic memory allocation function: malloc.

misra118.c(10):Dynamic heap memory allocation shall not be used.Violation: MISRA Guidelines item 118Detected use of dynamic memory allocation function: realloc.

misra118.c(12):Dynamic heap memory allocation shall not be used.Violation: MISRA Guidelines item 118Detected use of dynamic memory allocation function: free.

misra118.c(16):Dynamic heap memory allocation shall not be used.Violation: MISRA Guidelines item 118Detected use of dynamic memory allocation function: calloc.

misra118.c(17):Dynamic heap memory allocation shall not be used.Violation: MISRA Guidelines item 118Detected use of dynamic memory allocation function: free.

126


A Note On Additional MISRA RulesThe following MISRA rules are not supported by CodeWizard, because they are not statically enforce-able. However, for completeness, they are documented in order to provide basic information about MISRA guidelines of which you should be aware.

MISRA-2Code written in languages other than C should only be used if there is a defined interface standard for object code to which the compilers-assemblers for both languages conform. Note: This rule is not stat-ically enforceable and thus is not implemented in CodeWizard.

MISRA-15Floating point implementations should comply with a defined floating point standard. Note: This rule is not statically enforceable and thus is not implemented in CodeWizard.

MISRA-116 All libraries used in production code shall be written to comply with the provisions of MISRA Guidelines document, and shall have been subject to appropriate validation. Note: This rule is not statically enforceable and thus is not implemented in CodeWizard.

CodeWizard's cwmfs UtilitySome of the MISRA rules implemented by CodeWizard require information from multiple compilation units. Normally, CodeWizard works on single compilation units; therefore, it was necessary to add a new commandline utility to CodeWizard to support analysis of multiple compilation units. This new functionality is used only for checking the new MISRA-25, MISRA-26 and MISRA-27 built-in rules on C code only.

Enforcing MISRA-25, MISRA-26 and MISRA-37To enforce these rules, the first thing that needs to be done is to collect symbol information from compi-lation units. This is done by using the CodeWizard command line tool cwmfs. Information collected is stored in .cwinfo files (symbol files), one symbol file per compilation unit.Symbol information can be collected in two ways:

1. As a "by-product" of standard analysis, in which case violations are reported if found in the compilation units being analyzed. To instruct CodeWizard to create symbol files, pass the -ZdoMfs option to the tool, along with other necessary options. For example, CodeWizard is normally invoked like this:

codewizard -DSOME_FLAG -I some/include/dir source.c

However, in order to create symbol files the -ZdoMfs option should be passed as well:

codewizard -ZdoMfs -DSOME_FLAG -I some/include/dir source.c

The source.c will be analyzed as usual, and any violations found will be reported. Also, a file .source.cwinfo will be created in the current directory. Note that the symbol file name is based on the name of the original source file.

2. CodeWizard can be run specifically to create symbol files, without reporting any violations. A special -ZskipSfs option will prevent CodeWizard from performing analysis on a single com-pilation unit. This option must be paired with the -ZdoMfs option described above, so that

127


CodeWizard collects the symbol information in data files. For example, normally CodeWizard is invoked like this:

codewizard -DSOME_FLAG source1.c source2.c

In order to skip static analysis and only create symbol files the -ZdoMfs and -ZskifSfs options should be passed as well:

codewizard -ZdoMfs -ZskipSfs -DSOME_FLAG source1.c source2.c

The files source1.c and source2.c will not be checked for rule violations reported. Instead, the two files .source1.cwinfo and .source2.cwinfo will be created in the current directory. Note that the symbol file names are based on the names of original source files.

Once created, symbol files can be analyzed by the new cwmfs tool bundled with CodeWizard installa-tion. In order to enforce MISRA rules 25, 26 and 27, the appropriate symbol files should be passed to the tool.

Examples of cwmfs UseFor example, assume that we have three source files: src1.c, src2.c and src3.c and that we want to check their conformance to MISRA rules 25, 26 and 27.

1. First, we create symbol files:

codewizard <COMPILER OPTIONS> -ZdoMfs -ZskipSfs src1.c src2.c src3.c

2. Now, once these symbols files are created, run the cwmfs tool to check the rules:

cwmfs .src1.cwinfo .src2.cwinfo .src3.cwinfo

The cwmfs tool will not analyze symbol information from the data files, and report MISRA rule 25, 26 and 27 violations, if any were detected.

Having to replace all .c file names with appropriate symbol file names in cwmfs command line may not be very convenient. Therefore, instead of passing symbol file names to the cwmfs tool, one can simply pass source file names like this:

cwmfs src1.c src2.c src3.c

and the cwmfs tool will try to deduce symbol file names based on source names passed on the com-mand line, by pre-pending the source file name with a dot ('.') and by replacing its file extension with cwinfo.

128


CodeWizard Options Related To Multiple Compilation Unit AnalysisThe following options are recognized by the CodeWizard command line program:

The following options are also recognized by the cwmfs command line program:

Any other options will be ignored by the cwmfs tool. It is therefore possible to use the same command line for both CodeWizard and cwmfs.

Option Description

-ZdoMfs Instructs CodeWizard to collect symbol information from source files specified at the command line, and creates (or updates existing) symbol files for every source file specified. Standard single compilation unit analysis will proceed as normal unless the -ZskipSfs option was also specified to disable the analysis.

-ZskipSfs Used, in addition to the -ZdoMfs option described above, to disable the standard single compilation unit analysis. This can be useful when CodeWizard is run solely to create sym-bol data files.

-Zomfs "symbol_file_name" Used, in addition to the -ZdoMfs option described above, to tell CodeWizard to use specified file name when creating symbol data file. Cannot be used when multiple source files are specified at the command line.

Option Description

[file] [...] The cwmfs tool expects symbol file names and/or corresponding source file names passed at the command line.

-ZignoreMissing If the source file name is passed to the tool, for which there is no corre-sponding symbol file present, the cwmfs tool will issue an error message and will not proceed with analysis. This option instructs the tool to ignore any source files for which there is no data file present, and proceed with analysis.

129

Meyers-Klaus Items

Meyers-Klaus ItemsMeyers-Klaus Items

Item MK-13Avoid calling virtual functions from constructors and destructorsThis rule detects when you call virtual functions from constructors and destructors. These errors are reported as violations of Item MK-13.

Example//// Meyers-Klaus Item 13//

class Base{public: Base() { init(); } // MK item 13 violation virtual ~Base();

protected: virtual void init(); int _i;};

void Base::init(){ _i = 10;}

class Derived : public Base{public: Derived() { init(); } // MK item 13 violation ~Derived();

private: void init();};

Category Item Description Violation Enabled?

Constructors/ Destructors/ Assignment

13 Avoid calling virtual functions from con-structors and destructors

SV Y

Implementation 23 Avoid using “...” in function parameter lists

I N

130

Meyers-Klaus Items

void Derived::init(){ _i = 20;}


Output[MK-item13.C:8] Avoid calling virtual functions fromconstructors and destructorsSevere violation: Meyers-Klaus item 13Virtual function init called.

[MK-item13.C:25] Avoid calling virtual functions fromconstructors and destructorsSevere violation: Meyers-Klaus item 13Virtual function init called.

131

Meyers-Klaus Items

Item MK-23Avoid using “...” in function parameter listsThis rule detects when you use “...” in function parameter lists. These errors are reported as violations of Item MK-23.


Example//// Meyers-Klaus Item 23//

class A{public: A() { init(); } virtual ~A();

private: void init(...); int _i;};

void A::init(...){ _i = 10;}


Output[MK-item23.C:17] Avoid using "..." in functionparameter listInformational: Meyers-Klaus item 23

132

Universal Coding Standard Items


Universal Coding Standard ItemsItem Description Violation Enabled?

2 Do not declare protected data members. V N

3 Do not declare the constructor or destructor to be inline. V N

4 Declare at least one constructor to prevent the compiler from doing so.

V N

5 Pointers to functions should use a typedef. V N

6 Never convert a const to a non-const. SV Y

7 Do not use the ?: operator. V N

8 Each class must declare the public, protected, and private sec-tions in that order.

V N

9 In the public section, entities shall be declared in the following order: Constructors, Destructors, Member functions, Member conversion functions, Enumerations, and other.

V N

10 In the protected section entities shall be declared in the following order: Constructors, Destructors, Member functions, Member conversion functions, Enumeration, and others.

V N

11 In the private section entities shall be declared in the following order: Constructors, Destructors, Member functions, Member conversion functions, Enumerations, and others.

V N

12 If a function has no parameters, use () instead of (void). V N

13 If, else, while, and do statements shall be followed by a block, even if it is empty.

V N

14 If a block is a single statement, enclose it in braces. V N

15 Whenever a global variable or function is used, use the :: opera-tor.

I N

16 Do not use public data members. V N

17 If a class has any virtual functions it shall have a virtual destruc-tor.

SV Y

18 Public member functions shall return const handles to member data.

SV Y

19 A class that has pointer members shall have an operator= and a copy constructor.

V N

20 If a subclass implements a virtual function, use the virtual key-word.

V N

21 Member functions shall not be defined in the class definition. V N

133


22 Ellipses shall not be used. V N

23 Functions shall explicitly declare their return types. V N

24 A pointer to a class shall not be converted to a pointer of a sec-ond class unless it inherits from the second.

SV Y

25 A pointer to an abstract class shall not be converted to a pointer that inherits from that class.

SV Y

26 Do not use the friend mechanism. V N

27 When working with float or double values, use <= and >= instead of ==.

SV Y

28 Do not overload functions within a template class. SV Y

29 Do not define structs that contain member functions. V N

30 Do not directly access global data from a constructor. SV Y

31 Do not use multiple inheritance. V N

32 Initialize all variables. V N

33 All pointers should be initialized to zero or to a legitimate address. V N

34 Always terminate a case statement with break. V N

35 Always provide a default branch for switch statements. V N

36 Do not use the goto statement. V N

37 Provide only one return statement in a function. I N

134


Item ucs-2Do not declare protected data membersDeclaring protected variables in a class results in the variables becoming visible to derived classes. This rule detects if you declare protected data members. These errors are reported as violations of Item ucs-02.

Reason for rule: When you declare data members protected instead of private, you expose members to derived classes that could be encapsulated in member functions.


Example/* * UCS item 02 - Do not declare protected data members */class A{protected:

int i; // UCS02 Violation};

Output[ucs02.C:6] Do not use protected data membersViolation: Universal Coding Standards item 2Class A declares the following protected data members: i

135


Item ucs-3Do not declare the constructor or destructor to be inlineInline functions that invoke other inline functions can be too complex for the compiler to make them inline. Because constructors always invoke the constructors of their base classes and member data, this rule reports use of inline constructors and destructors as violations of Item ucs-03.

Reason for rule: Portability. Functions that invoke other inline functions often become too complex for the compiler to be able to make them inline, despite the fact that they appear to be small. This problem is especially common with constructors and destructors. A constructor always invokes the constructors of its base classes and member data before executing its own code. If you avoid making constructors and destructors inline, you will make the code more portable to compilers that get confused when gen-erating complex nested inline functions.


Example /* * UCS item 03 - Do not declare the constructor or destructor * to be inline */class A{public:

A() {} // UCS03 Violation~A() {} // UCS03 Violation

};

Output[ucs03.C:6] Do not define any constructor to be inlineViolation: Universal Coding Standards item 3Class A defines an inline constructor

136


Item ucs-4Declare at least one constructor to prevent the compiler from doing soIf you do not write at least one constructor in a class, the compiler will write a public constructor for you by default. This rule detects if you do not declare at least one constructor. This error is reported as a violation of Item ucs-04.

Reason for rule: Readability. If you follow this rule, you will make class initialization explicit and pre-vent the compiler from initializing members improperly, especially pointer members.


Example /* * UCS item 04 - Declare at least one constructor to * prevent the compiler from doing so */class A{}; // UCS04 Violation

Output[ucs04.C:7] Declare at least one constructor to prevent the compiler from doing soViolation: Universal Coding Standards item 4Class A does not define any constructors

Item ucs-5Pointers to functions should use a typedefThis rule detects when pointers to functions do not use a typedef. Using a typedef when writing pointers to functions results in more readable code that is easier to maintain and port. These errors are reported as violations of Item ucs-05.

Reason for rule: When you use a typedef, you provide greater readability for function pointers.


Example/* * UCS item 05 -Pointers to functions should use a typedef */void (*foo) (int); // UCS05 Violation

Output[ucs05.C:7] Pointers to functions shall be implemented with a typedefViolation: Universal Coding Standards item 5

137


Item ucs-6Never convert a const to a non-constUsing explicit type conversions to convert const member data to non-const will prevent the com-piler from allocating constants in ROM. This rule detects if you convert a const to a non-const. These errors are reported as violations of Item ucs-06.

Reason for rule: Converting const to non-const can undermine the data integrity by allowing val-ues to change that are assumed to be constant. This practice also reduces the readability of the code, since you cannot assume const variables to be constant.

Example/* * UCS item 06 - Never convert a const to a non-const */int main(){

const int a = 10;int b;

b = (int)a; // UCS06 Violation

return 0;}

Output[ucs06.C:10] Never convert a const to a non-constSevere violation: Universal Coding Standards item 6

Item ucs-7Do not use the ?: operatorThis rule detects if you use the ?: operator. This error is reported as a violation of Item ucs-07.

Reason for rule: The ?: operator is difficult to read and leads to code obfuscation.


Example/* * UCS item 07 - Do not use the ?: operator */int main(){

return (1 ? 1 : 0); // UCS07 Violation};

Output[ucs07.C:7] Avoid using the ?: operatorViolation: Universal Coding Standards item 7

138


Item ucs-8Each class must declare the public, protected, and private sections in that orderUsing the above convention, everything of general interest to a user (the public section) is gathered in the beginning of the class definition, with the protected items next, while items of the least general interest (the private section) are gathered last. This rule reports violations of this convention as viola-tions of Item ucs-08. Reason for rule: Readability. Note: This item is suppressed by default.

Example/* * UCS item 08 - Each class must declare the public, * protected, and private sections in that order */class A{public:

A();

private: // UCS08 Violationvoid foo();

protected:void bar();

};

Output[ucs08.C:7] Each class must declare the public, protected, and private sec-tions in that orderViolation: Universal Coding Standards item 8class A declares these sections out of order

139


Item ucs-9In the public section, entities shall be declared in the following order: Constructors, Destructors, Member functions, Member conversion functions, Enumerations, and otherFollowing the above ordering convention makes it easier for those unfamiliar with a class to figure out its functionality. This rule reports violations of this convention as violations of Item ucs-09.

Reason for rule: Readability. Note: This item is suppressed by default.

Example /* * UCS item 09 - In the public section entities shall be * declared in the following order: Constructors, * Destructors, Member functions, Member conversion * functions, Enumerations, and other. */class A{public:

A();int foo(); // UCS09 Violation~A();

};

Output[ucs09.C:9] In the public section of a class items shall be declared in the following order: Constructors, Destructor, Member Functions, Member Opera-tor Function, Enumerations, otherViolation: Universal Coding Standards item 9

140


Item ucs-10In the protected section entities shall be declared in the following order: Constructors, Destructors, Member functions, Member conversion functions, Enumeration, and otherFollowing the above ordering convention makes it easier for those unfamiliar with a class to figure out its functionality. This rule reports violations of this convention as violations of Item ucs-10.


Example /* * UCS item 10 - In the protected section entities shall * be declared in the following order: Constructors, * Destructors, Member functions, Member conversion * functions, Enumerations, and other. */class A{protected:


};

Output[ucs10.C:9] In the protected section of a class items shall be declared in the following order: Constructors, Destructor, Member Functions, Member Operator Function, Enumerations, otherViolation: Universal Coding Standards item 10

141


Item ucs-11In the private section entities shall be declared in the following order: Constructors, Destructors, Member functions, Member conversion functions, Enumerations, and otherFollowing the above ordering convention makes it easier for those unfamiliar with a class to figure out its functionality. This rule reports violations of this convention as violations of Item ucs-11.


Example /* * UCS item 11 - In the private section entities shall * be declared in the following order: Constructors, * Destructors, Member functions, Member conversion * functions, Enumerations, and other */class A{private:


};

Output[ucs11.C:9] In the private section of a class items shall be declared in the following order: Constructors, Destructor, Member Functions, Member Opera-tor Function, Enumerations, otherViolation: Universal Coding Standards item 11

142


Item ucs-12If a function has no parameters, use () instead of (void)This rule detects if you use (void) instead of () if a function has no parameters. Maintaining this con-sistency of declarations results in easier code readability. These errors are reported as violations of Item ucs-12.


Example/* * UCS item 12 - If a function has no parameters use () * instead of (void) */int foo(void); // UCS12 Violation

Output[ucs12.C:5] If a function has no formal parameters, use () instead of (void)Violation: Universal Coding Standards item 12function foo uses (void).

143


Item ucs-13If, else, while, and do statements shall be followed by a block, even if it is emptyTo avoid confusion when reading a piece of code, you should follow loop statements with an empty block rather than with a semi-colon, which is easy to miss. This rule detects if you do not follow If, else, while, and do statements with a block. These errors are reported as violations of Item ucs-13.

Reasons for rule: Readability and maintainability. This rule also helps to prevent errors such as:

while(1); { // infinite loop do_something();}

Note: This item is suppressed by default. See also Item ucs_14.

Example /* * UCS item 13 - If, else, while, and do statements shall * be followed by a block, even if it is empty */int main(){

if (1) ; // UCS13 Violationreturn 0;

}

Output[ucs13.C:8] If, else, while, and do statements shall be followed by a block, even if it is emptyViolation: Universal Coding Standards item 13

144


Item ucs-14If a block is a single statement, enclose it in bracesTo avoid causing confusion for those reading your code, you should always enclose a single-statement block in braces. This rule can detect if single-statement blocks are not enclosed in braces. These errors are reported as violations of Item ucs-14.

Reasons for rule: Readability and maintainability. If you are maintaining the code and you see this:

if (condition) do_something();

you may be tempted to update it like this:

if (condition) do_preparation(); do_something();

instead of like this:

if (condition) { do_preparation(); do_something();}

If you write the original code like this:

if (condition) { do_something();}

there will be less room for error for the maintainer of the code.


Example /* * UCS item 14 - If a block is a single statement, * enclose it in braces */int main(){

if (1) return 1; // UCS14 Violation

}

Output[ucs14.C:7] If a block is a single statement, it shall be enclosed in bracesViolation: Universal Coding Standards item 14

145


Item ucs-15Whenever a global variable or function is used, use the :: operatorThis rule detects if you do not use the :: operator whenever a global variable or function is used. Using the :: operator in these situations will make it easier to determine which variable is being used. These errors are reported as violations of Item ucs-15.

Reasons for rule: Readability and maintainability. Using the :: operator helps the maintainer of code distinguish quickly between global variables and local variables; it also allows more freedom in naming local variables without the chance of clashing with global names.


Example /* * UCS item 15 - Whenever a global variable or function is * used, use the :: operator */int a = 10;int main(){

int b = a; // UCS15 Violation}

Output[ucs15.C:9] Whenever a global function or variable is referenced, use the :: operatorInformational: Universal Coding Standards item 15the following globals are referenced without the :: operator: a

146


Item ucs-16Do not use public data membersUsing public variables is contrary to the principle of data encapsulation and can allow the value of the variable to be changed by any user of the class. This rule detects if you use public data members. These errors are reported as violations of Item ucs-16.

Reason for rule: Data hiding. If you follow this rule, you will insulate the class interface from the class implementation. You will also provide consistency for users of the class to access data through mem-ber functions every time. Internally, the class may change which data types are used to store the data without breaking the interface.


Example /* * UCS item 16 - Do not use public data members */class A{public:

int a; // UCS16 Violation};

Output[ucs16.C:6] Do not specify public data membersViolation: Universal Coding Standards item 16Class A has the following public data members: a

147


Item ucs-17If a class has any virtual functions it shall have a virtual destructorDeclaring virtual destructors in classes that have virtual functions causes the compiler to call destruc-tors for each class from which the object inherits. This rule detects if you write a virtual function without also writing a virtual destructor. These errors are reported as violations of Item ucs-17.

Reason for rule: Prevents memory leaks in derived classes. A class that has virtual functions is intended to be used as a base class, so it should have a virtual destructor to guarantee that the destructor will be called when the derived object is referenced through a pointer to the base class.

Example /* * UCS item 17 - If a class has any virtual functions * it shall have a virtual destructor */class A // UCS17 Violation{public:

~A();virtual int foo();

};

Output[ucs17.C:7] If a class has virtual functions it shall have a virtual destructorSevere violation: Universal Coding Standards item 17class A has virtual functions without a virtual destructor.

148


Item ucs-18Public member functions shall return const handles to member dataThis rule helps avoid problems that point to deallocated memory. Any public member functions that do not return const handles to member data are reported as violations of Item ucs-18.

Reason for rule: When you provide non-const handles to member data, you undermine encapsula-tion by allowing callers to modify member data outside of member functions.

Example /* * UCS item 18 - Public member functions shall return const * handles to member data */class A{public:

int* foo();

private:int a;

};int* A::foo(){

return &a; // UCS18 Violation}

Output[ucs18.C:17] Public member functions shall always return const handles to member dataSevere violation: Universal Coding Standards item 18

149


Item ucs-19A class that has pointer members shall have an operator= and a copy constructorDefault memberwise initialization is generally insufficient for classes that contain pointer members because the destructor is invoked for every class object, which may result in dangling references and other program errors. This rule checks to see if classes that have pointer members also have an operator= and a copy constructor. These errors are reported as violations of Item ucs-19.

Reason for rule: Prevents memory leaks and data corruption. If you do not define a copy constructor, the default constructor will be used, which is usually not the desired behavior when a class has pointer members.


Example /* * UCS item 19 - A class that has pointer members shall have * an operator=and a copy constructor */

class A{public: A(); ~A();

private: int *a;}; // UCS19 Violation

Output[ucs19.C:7] If a class has pointer members it must define a copy constructor and op=Violation: Universal Coding Standards item 19

150


Item ucs-20If a subclass implements a virtual function, use the virtual keywordUsing the virtual keyword whenever a subclass implements a virtual function makes the code more readable, because the reader does not have to refer back to the base class to see that the function is virtual. This rule detects if a subclass implements a virtual function without using a virtual keyword. These errors are reported as violations of Item ucs-20.

Reasons for rule: Readability, as well as more intuitive behavior for deep inheritance hierarchies, in that functions that are virtual in a base class will remain virtual in all inherited classes.


Example /* * UCS item 20 - If a subclass implements a virtual * function, use the virtual keyword */class B{public: virtual int foo();};

class D : public B{public: int foo(); // UCS20 Violation};

Output[ucs20.C:12] If a subclass redefines a virtual function, use the keyword virtual in that function's declarationViolation: Universal Coding Standards item 20

151


Item ucs-21Member functions shall not be defined in the class definitionFunctions defined within the class definition are implicitly inline; however, defining member functions within a class definition also makes the class definition less compact and harder to read. This rule detects if you define member functions in the class definition. These errors are reported as violations of Item ucs-21. Note: This item is suppressed by default.

Reason for rule: Encourages better data hiding by separating interface and implementation.

Example /* * UCS item 21 - Member functions shall not be defined in * the class definition */class A{public:

int foo() {}; // UCS21 Violation};

Output[ucs21.C:7] Member functions shall not be defined within the class defini-tionViolation: Universal Coding Standards item 21class A defines the following functions within the class definition foo

152


Item ucs-22Ellipses shall not be usedDevelopers should avoid using unspecified function arguments (...), as this deters the strong type checking provided by C++. This rule detects if ellipses are used. These errors are reported as viola-tions of Item ucs-22.

Reason for rule: Ellipses defeat the benefits of type safety. Use default arguments instead. Note: This item is suppressed by default.

Example /* * UCS item 22 - Ellipses shall not be used */class A{public:

int foo(int, ...); // UCS22 Violation};

Output[ucs22.C:8] Ellipses shall not be usedViolation: Universal Coding Standards item 22function foo uses ellipses.

153


Item ucs-23Functions shall explicitly declare their return typesIf return types are not explicitly declared, functions will implicitly receive int as the return type. How-ever, the compiler will still generate a warning for a missing return type. To avoid confusion, functions that do not return a value should specify void as the return type.

This rule detects if you do not explicitly declare return types in functions. These errors are reported as violations of Item ucs-23.

Reason for rule: Readability. If you do not specify a return type, the compiler will assume either void or int, depending on the compiler. You should explicitly declare the return type so that the result will be unambiguous. Note: This item is suppressed by default.

Example /* * UCS item 23 - Functions shall explicitly declare their * return types */

foo(); // UCS23 Violation

Output[ucs23.C:5] Functions shall explicitly declare their return typeViolation: Universal Coding Standards item 23

154


Item ucs-24A pointer to a class shall not be converted to a pointer of a second class unless it inherits from the secondThis rule detects if a pointer to a class is converted to a pointer of a second class when the first class does not inherit from the second. Such "invalid" downcasting can result in wild pointers and other disasters. Use virtual function calls instead. These errors are reported as violations of Item ucs-24.

Reason for rule: If you violate this rule, you make assumptions about member layout of classes that may be subject to change, producing memory and data corruption bugs.

Example/* * UCS item 24 - A pointer to a class shall not be converted * to a pointer of a second class unless it inherits from the * second */

class A { };

class B { };

class D : public B { };

int main() { A *a; B *b; D *d;

b = (B*)a; // UCS24 Violation d = (D*)b; // UCS24 Violation b = (B*)d; // OK

return 0; }

Output[ucs24.C:14] A pointer to a class may not be converted to a pointer of a second class unless the first class inherits from the secondSevere violation: Universal Coding Standards item 24

155


Item ucs-25A pointer to an abstract class shall not be converted to a pointer that inherits from that classDowncasting from a virtual base is always illegal. This rule detects pointers to abstract classes that are converted to pointers that inherit from that class. These errors are reported as violations of Item ucs-25.

Reason for rule: When appropriate functions are virtual, converting them is unnecessary and confus-ing.

Example /* * UCS item 25 - A pointer to an abstract class shall * not be converted to a pointer that inherits from * that class */class B{public: virtual int foo() = 0;};class D : public B{public: int foo();};

int main(){ B *b; D *d;

d = (D*)b; // UCS25 Violation}

Output[ucs25.C:23] A pointer to an abstract class shall not be converted to a pointer of a class that inherits from the abstract classSevere violation: Universal Coding Standards item 25

156


Item ucs-26Do not use the friend mechanismUsing friend functions is usually a sign of an inadequate interface. Fixing the interface, rather than granting friendship, is the best approach. This rule detects if you use the friend mechanism. These errors are reported as violations of Item ucs-26.

Reason for rule: Using the friend mechanism undermines data-hiding and encapsulation. Note: This item is suppressed by default.

Example /* * UCS item 26 - Do not use the friend mechanism */

int foo();

class A{

friend int foo(); // UCS26 Violation};

Output[ucs26.C:8] Avoid using the friend mechanismViolation: Universal Coding Standards item 26Class A has the following friends: foo

157


Item ucs-27When working with float or double values, use <= and >= instead of ==Two different paths to the same number will not always lead to the same number. For example, float-ing-point numbers that should be equal are not always equal. Using <= and >= instead of == is the rec-ommended solution to the problem.

This rule detects if you use == when working with float or double values. These errors are reported as violations of Item ucs-27.

Reason for rule: Using <= and >= helps prevent rounding errors.

Example /* * UCS item 27 - When working with float or double * values, use <= and >= instead of == */int main(){

float a = 1.0;float b = 2.0;

if (a == b) { // UCS27 Violationreturn 1;

}

return 0;}

Output[ucs27.C:11] When working with float or double expressions, use less than or equal to or greater than or equal to instead of ==Violation: Universal Coding Standards item 27

158


Item ucs-28Do not overload functions within a template classOverloading functions within a template class can lead to problems if the element type appears explic-itly in one of them. This rule detects if you overload functions within a template class. These errors are reported as violations of Item ucs-28.

Reason for rule: Overloading functions may indicate a design flaw in the template class.

Example /* * UCS item 28 - Do not overload functions within a template * class */template <class T> class A{public:

int foo(T);int foo(int); // UCS28 Violation

};

Output[ucs28.C:6] Do not overload functions within a template classSevere violation: Universal Coding Standards item 28The following member functions of class Afoohave potentially conflicting overloaded versions

159


Item ucs-29Do not define structs that contain member functionsMember functions should be contained in classes, not structs, because classes support both multiple instances and encapsulation. Structs are also often entirely public: whereas the default access level for members and base classes of a class is private.

This rule detects if you define structs that contain member functions. These errors are reported as vio-lations of Item ucs-29.

Reason for rule: Readability. It is generally expected that types with member functions are classes, and many programmers still think of structs in terms of their original meaning in C.


Example /* * UCS item 29 - Do not define structs that contain member * functions */struct A{public:

int foo(); // UCS29 Violation};

Output[ucs29.C:6] Do not define structs that contain objects with member functionsViolation: Universal Coding Standards item 29struct A contains the following member functions: foo

160


Item ucs-30Do not directly access global data from a constructorDirectly accessing global data from a constructor is risky because the global object may not yet exist when the "other" static object is initialized. This rule detects if you directly access global data from a constructor. These errors are reported as violations of Item ucs-30.

Reason for rule: The order of initialization of static objects defined in different compilation units is not defined in the C++ language definition. Therefore, accessing global data from a constructor may result in reading from uninitialized objects.

Example /* * UCS item 30 - Do not directly access global data from a * constructor */int a;class A{public:

A();private:

int b;};A::A(){ b = a; // UCS30 Violation}

Output[ucs30.C:8] Do not directly access global data from a constructorSevere violation: Universal Coding Standards item 30Constructor accesses the following global variables: a

161


Item ucs-31Do not use multiple inheritanceUsing multiple inheritances can result in strange class hierarchies and less flexible code. Because in C++ there may be an arbitrary number of instances of a given type, it could be that direct inheritance from a class may only be used once (see the example below). This rule detects if you use multiple inheritances. These errors are reported as violations of Item ucs-31.

Reasons for rule: Clarity, maintainability. Following this rule prevents ambiguity when classes derive from one object through multiple objects as in the “diamond of death” illustrated in the example.


Example /* * UCS item 31 - Do not use multiple inheritance */class B {};class A : public B {};class C : public B {};class D : public A, public C {};// UCS31 Violation

Output[ucs31.C:8] Do not use multiple inheritanceViolation: Universal Coding Standards item 31class D inherits multiply from the following classes: A, C

162


Item ucs-32Initialize all variablesA variable must always be initialized before it is used. By always initializing all variables, rather than assigning values to them before they are first used, your code is faster and more efficient since no tem-porary objects are created for the initialization. This rule detects if you fail to initialize all variables. These errors are reported as violations of Item ucs-32.

Reason for rule: Following this rule prevents reading from uninitialized variables. Note: This item is suppressed by default.

Example /* * UCS item 32 - Initialize all variables */int main(){

int a; // UCS32 Violation};

Output[ucs32.C:6] Initialize all variablesViolation: Universal Coding Standards item 32The following variables were not initialized when declared: a

163


Item ucs-33All pointers should be initialized to zero or to a legitimate addressInitializing pointers to zero or to a legitimate address makes the code more efficient and helps you catch signals and exceptions. This rule detects if you do not initialize all pointers in this manner. These errors are reported as violations of Item ucs-33.

Reason for rule: Initializing pointers to zero or to a legitimate address makes it easier to check if a pointer is valid. Note: This item is suppressed by default.

Example /* * UCS item 33 - All pointers should be initialized to zero * or a legitimate address */int main(){

int *a; // UCS33 Violation };

Output[ucs33.C:6] All pointers should be initialized to zero or a legitimate addressViolation: Universal Coding Standards item 33The following pointers were not initialized when declared: a

164


Item ucs-34Always terminate a case statement with breakIf the code following a case statement is not terminated with break, execution continues after the next case statement, meaning poorly tested code can be erroneous and yet still appear viable. This rule detects if you fail to terminate a case statement with break. These errors are reported as violations of Item ucs-34.

Reasons for rule: Readability, maintainability. Note: This item is suppressed by default.

Example /* * UCS item 34 - Always terminate a case statement with break */int main(){

int a = 0;

switch (a) {case 0:

return 0;case 1:

a = 1; // UCS34 Violation}

}

Output[ucs34.C:13] Always terminate a case statement with breakViolation: Universal Coding Standards item 34

165


Item ucs-35Always provide a default branch for switch statementsSwitch statements must always provide a default branch that handles unexpected cases. This rule detects if you fail to provide a default branch for switch statements. These errors are reported as vio-lations of Item ucs-35.

Reason for rule: Maintainability. If all desired cases are handled outside of default, then default can be used for error checking. Note: This item is suppressed by default.

Example /* * UCS item 35 - Always provide a default branch for switch * statements */int main(){

int a = 0;

switch (a) {case 0:

return 0;case 1:

return 1;} // UCS35 Violation

}

Output[ucs35.C:9] Always provide a default branch for switch statementsViolation: Universal Coding Standards item 35

166


Item ucs-36Do not use the goto statementThe goto statement interrupts the control flow, makes the code more difficult to understand, and has limits on when it can be used. This rule detects if you use the goto statement. These errors are reported as violations of Item ucs-36.

Reasons for rule: Readability, maintainability. Anything written with a goto statement can usually be written more clearly without a goto.


Example /* * UCS item 36 - Do not use the goto statement */int main(){

goto end; // UCS36 Violation

end:return 0;

}

Output[ucs36.C:7] Do not use the goto statementViolation: Universal Coding Standards item 36

167


Item ucs-37Provide only one return statement in a functionMinimizing the number of return statements in a function makes the function easier to understand. This rule detects if you provide more than one return statement in a function. These errors are reported as violations of Item ucs-37.

Reasons for rule: Readability, maintainability, debugging. It is easier to follow the program flow if there is only one return statement.


Example /* * UCS item 37 - Provide only one return statement in * a function */int main(){

if (0) {return 0;

} else {return 1; // UCS37 Violation

}}

Output[ucs37.C:6] Provide only one return statement in a functionInformational: Universal Coding Standards item 37

168

User Items

User ItemsUser ItemsUser items are C and C++ coding standards that you have created or that you can customize. Thereare two types of user items, coding standards that you have designed in RuleWizard and coding stan-dards written by Parasoft that can be modified/customized in RuleWizard. These rules are divided intoseveral categories, as shown in the following table:

Category Description

Naming Convention Identifiers in the 100-199 range are reserved for Naming Conventions and have names beginning with "Name." These rules do not represent code which is dangerous or incorrect; rather, they are schemes for naming vari-ables, functions, classes, and so on. When an entire development group agrees on a common convention, code becomes easier to read and more easily understood. Included in this category are the Hungarian naming con-ventions.

A common element in the Naming Conventions rules is the use of regular expressions. The regular expression format is based on that used in Perl. These regular expressions can be modified to enforce whatever Naming Convention your development group agrees upon.

Miscellaneous Identifiers in the 200-399 range are reserved for miscellaneous C and C++ coding standards that users can customize.

Text Rules Identifiers in the 400-499 range are reserved for Text rules. Rules in this section are used to check programming styles. They are derived from vari-ous coding standards, including Motorola's C and MISRA’s C coding stan-dards.

Metrics Identifiers in the 600-699 range are reserved for Metrics and have names beginning with "Metric."

These rules have a slightly different usage than other rules. Whereas most rules are designed to find patterns which represent bad programming prac-tices, the metrics rules are used primarily to produce numbers representing size and complexity of code. Because of this, most outputs in the metrics rules include a "$count" expression in the Output, which prints the number of occurrences found of that particular pattern. The collectors have count expressions which should be modified according to what cut-off point you are interested in seeing.

For example, MetricInheritance.rule reports the number of classes which a given class derives from directly or indirectly. The default is to report this number for classes where the ancestor count is greater than 10. If you want a report on the ancestors for every class, set the count expression to "$$>=0". Likewise, if you only want it to report on classes which derive from over 20 base classes, change the count expression to "$$>20". For a discussion of what metrics are and how to use them, see Mark Shroeder's article, "A Practical Guide to Object-Oriented Metrics" in IT Pro, November/December, 1999.

169

User Items

Violations of user items are labeled “user-<item number>.” You can suppress individual user rules or alluser rules as you would suppress rules in any other category. You can also enable/disable these rulesby checking or clearing options in the Control Panel’s Rules tab.

For more information on creating, modifying, and enforcing custom coding standards, open RuleWiz-ard by clicking the RuleWizard button in the Visual C++ Toolbar, then choose Help> View in theRuleWizard GUI to open the RuleWizard Users Guide.

Note: All rules are assumed to work for both C and C++ unless a specific language is otherwise notedwithin the rule itself. All rules are suppressed unless otherwise noted in the rule text.

C Rules Identifiers in the 700-799 range are reserved for C and C++ rules. They are derived from a variety of sources, including Motorola's C Coding Stan-dards.

32-bit to 64-bit Porting Rules

Identifiers in the 800-899 range are reserved for rules that flag coding con-structs that are dangerous when you are migrating from a 32-bit architec-ture to a 64-bit architecture.

Rule RuleID Description Violation

3264bit-32BitMultiplication 808 Do not assign the value 32-bit mul-tiplication to type long

V

3264bit-BinaryOverFlow 806 Operation will not resolve to 64 bits V

3264bit-CastPointerToUINT 811 Do not cast pointer to UINT type V

3264bit-HardCodeValueOffset 817 Do not use hard coded value of off-set in structures

PSV

3264bit-HardCodeValueOffset2 817 Do not use hard coded value of off-set in structures

PSV

3264bit-HexConstant 812 Do not use hex constants V

3264bit-ImplicitTruncation 802 Avoid writing code that will result in losing data

V

3264bit-ImplicitTruncation2 802 Avoid writing code that will result in losing data

V

3264bit-IntConstantToLongValue 809 Constant assignment to long should not involve int literals

V

3264bit-IntConstantToLongValue2 809 Constant assignment to long should not involve int literals

V

3264bit-IntLiteralToLongInit 807 Do not assign literal to type long V

3264bit-IntPointerCast 810 Do not cast pointer to int type V

3264bit-IntToLongPointerCast 805 Incompatible cast PSV

3264bit-LongDouble 816 Possible Truncation V

3264bit-LongToDoubleCast 816 Possible Truncation V

Category Description

170

User Items

3264bit-LongToDoubleCast2 816 Possible Truncation V

3264bit-LongToIntPointerCast 804 Do not cast long to int pointer PSV

3264bit-LongVariableSuffixes 818 Do not use i64 or L suffixes directly V

3264bit-OperandCast 803 Use explicit cast on operand of type long

V

3264bit-Union 813 Avoid union if possible V

3264bit-UsingLong 814 Avoid using long V

3264bit-VariableDefinition 815 Do not use a #define that the com-piler cannot type check

V

3264bit-VariableDefinition2 815 Do not use a #define that the com-piler cannot type check

PV


V


V

ArrayElementAccess 733 Array elements shall be accessed by the array operator [ ]

V

AssignAllMemberVar 302 Assign to all member variables in operator= functions

V

AssignCharTooHigh 707 Avoid assigning out-of-range value to char type

V

AssignCharTooLow 707 Avoid assigning out-of-range value to char type

V

AssignmentOperator 216 Declare an assignment operator for classes which have data members that are pointers

V

AssignUnCharTooHigh 706 Avoid assigning out-of-range value to unsigned char type

V

AssignUnCharTooLow 706 Avoid assigning out-of-range value to unsigned char type

V

BaseDestructors 218 Make destructors virtual for all base classes

V

BitwiseInCondition 742 Do not use the bitwise operator in conditional expressions

PV

BreakInForLoop 317 Do not use break in for loops SV


171

User Items

CastFuncPtrToPrimPtr 717 Do not type cast pointers to primi-tive types for variables that have been declared as pointers to func-tions

V

CastPointer 207 Do not cast pointers to non-pointers V

CastUnsigned 205 Do not cast an unsigned char to an unsigned int

V

CharacterTest 721 Use the ctype.h facilities for charac-ter test

PV

CharCompareLeft 213 Do not compare chars to constants out of char range

SV

CharCompareRight 214 Do not compare chars to constants out of char range

SV

CommaOperator 734 The comma operator shall only be used in for statements and variable declarations

V

ConditionCurlyBraces 436 All conditional statements shall use { and } to identify the body of code associated with the condition

PSV

ConditionCurlyBraces2 437 All conditional statements shall use { and } to identify the body of code associated with the condition

PSV

ConditionCurlyBraces3 438 All conditional statements shall use { and } to identify the body of code associated with the condition

PSV

ConstParam 306 Declare reference parameters as const references whenever possi-ble

V

ConstPointerFunctionCall 737 Const data type should be used for pointers in function calls if the pointer is not to be changed

V

DeclareArrayMagnitude 726 Do not declare the size of an array when the array is passed into a function as a parameter

V

DeclareBitfield 710 Do not declare member variables as bitfields

I

DeclareExplicitConstructor 319 Do not use the keyword 'explicit' for a constructor

I

DeclareMutable 320 Do not declare member variables with the 'mutable' keyword

I


172

User Items

DeclareRegister 709 Do not declare local variables with the 'register' keyword

I

DeclareStaticLocal 711 Do not declare local variables with the 'static' keyword

I

DeclDimArray 725 Do not declare the size of an array when the array is initialized

PV

DefineNamingConvention 407 All "#define" constants shall be in uppercase

I

DeleteIfNew 212 Write operator delete if you write operator new

V

DeleteNonPointer 206 Do not call delete on non-pointers SV

DoNotUseTabs 442 Tabs that do not use ASCII spaces should not be used

I

DoWhile 200 Prefer while statements over do statements

I

EnumKeyword 201 Do not use the ‘enum’ keyword to declare a variable in C++

I

EnumNamingConvention 729 In an enumerated list, list members (elements) shall be in uppercase and names or tags for the list shall be in lowercase

PV

EOSDefinition 415 Incorrect End-Of-String (EOS) defi-nition

PV

EOSUsage 401 EOS shall be used to terminate a string rather than using backslash-zero '\0'

PSV

EqualityFloatLeft 208 Do not check floats for equality; check for greater than or less than

SV

EqualityFloatRight 208 Do not check floats for equality; check for greater than or less than

SV

ExplicitEnumValues 740 When using enum, the values of each member should be explicitly declared

PV

ExplicitLogicalTest 738 Use explicit logical tests in condi-tional expressions

V

ExplicitLogicalTests 402 An explicit logical comparison should be used in conditional expression

V

ExprInSizeof 743 Avoid passing expressions like assignment to sizeof() operators

V


173

User Items

FalseDefinition 411 If FALSE is to be defined, and is not already defined, FALSE should be 0

I

FalseTypeDef 413 If FALSE is to be defined, and is not already defined, FALSE should be 0

I

FileNameConvention 735 Use lowercase for file names PV

ForLoopVarAssign 300 Do not assign to loop control vari-ables in the body of a for loop

V

FractionLoss 211 Do not assign the dividend of two ints to a float

V

FuncModifyGlobalVar 701 Avoid functions that modify the glo-bal variable

V

FunctionCurlyBraces 435 All curly braces "{ }" shall appear on a line by themselves

V

FunctionCurlyBraces2 435 All curly braces "{ }" shall appear on a line by themselves

V

FunctionSize 724 Avoid functions with over 50 lines I

GlobalPrefixExclude 703 Global prefixes should only be used for global variables

I

GlobalVarFound 702 Avoid global variables I

HardCodeValue 406 "#define" or enum constants should be used instead of hard coded val-ues whenever possible

V

HardCodeValueWithZero 406 "#define" or enum constants should be used instead of hard coded val-ues whenever possible

V

HeaderInitialization 722 Headers should not contain any ini-tialization

PV

IfAssign 202 Avoid assignment in if statement condition

SV

IfElse 316 All if statements should have an else clause

I

ImplicitUnsignedInit 741 Do not initialize unsigned integer variables with signed constants

V

InitCharOutOfRange 707 Avoid assigning out-of-range value to char type

V

InitPointerVar 318 Initialize all pointer variables V


174

User Items

InitUnCharOutOfRange 706 Avoid assigning out-of-range value to unsigned char type

V

LineLength 403 Physical lines shall be less than eighty characters

PSV

LocalVariableNames 731 Local variable names shall be low-ercase

PV

LongConst 210 Use capital 'L' instead of lowercase 'l' to indicate long

SV

MacroSize 404 The length of a macro should not exceed 10 lines

V

MacroWithinInclude 446 Do not use macros in the include statement

PSV

ManyCases 305 Avoid switch statements with many cases

I

MetricBlockofCode 604 Number of blocks of code per func-tion

V

MetricBreakEncap 600 Avoid using global in member func-tions

V

MetricFuncCall 602 Number of function calls V

MetricInheritance 601 Class inheritance level V

MetricMembers 607 Number of data member(s) per class

V

MetricMethod 605 Number of method(s) per class V

MetricParam 603 Number of parameter(s) per method

V

MetricPrivateMembers 608 Number of private data member(s) per class

V

MetricPrivateMethod 606 Number of private methods per class

V

MetricProtectedMembers 608 Number of protect data member(s) per class

V

MetricProtectedMethod 606 Number of protected method(s) per class

V

MetricPublicMembers 608 Number of public data member(s) per class

V

MetricPublicMethod 606 Number of public method(s) per class

V


175

User Items

ModifyInCondition 708 Do not use operator ++ or -- in the conditional expression of if, while, or switch

PV

NameBool 110 Begin all boolean type variables with 'b'

I

NameClass 100 Begin class names with an upper-case letter

I

NameConflict 705 Avoid internal or external name conflict

V

NameConstantVar 101 Begin constant variables with ‘c’ I

NameDataMember 102 Begin class data member names with ‘its’

I

NameDouble 110 Begin all double type variable with 'd'

I

NameEnumType 103 Enumerated type name shall begin with an uppercase letter prefixed by the software element and suffixed by ‘_t’

I

NameFloat 110 Begin all float type variables with 'f' I

NameFunction 108 Begin function names with upper-case letter

I

NameGlobalVar 104 Begin global variable names with ‘the’

I

NameInt 110 Begin all integer type variable with 'i'

I

NameIsFunction 109 'is' functions should return bool val-ues

V

NameLongInt 110 Begin all long integer variables with 'li'

I

NamePointerVar 105 Prefix a variable type 'pointer' with a 'p' character

I

NameShortInt 110 Begin all short integer variables with 'si'

I

NameSignedChar 110 Begin all signed character variables with 'c'

I

NameString 110 Begin all terminated characters string variables with 'sz'

I


176

User Items

NameStructType 106 Struct type name shall begin with an uppercase letter prefixed by software element and suffixed by '_t'

I

NameUnsignedChar 110 Begin all unsigned character type variables with 'uc'

I

NameUnsignedInt 110 Begin all unsigned integer type vari-ables with ‘ui’

I

NameVariable 107 Begin all variables with a lowercase letter

I

NamingStructUnionMembers 730 Use lowercase letters for structure and union member names

PV

NoInputParamsInMacros 450 No input parameters in macros V

NonScalarTypedefs 728 Append names of non-scalar type-defs with "_t".

PV

NullDefinition 414 Incorrect NULL definition I

NumberFunctionParam 736 Avoid functions with more than 5 parameters

V

NumberMacroParams 405 Macros should not use more than 5 parameters

V

OneStatementPerLine 443 Only one statement shall be allowed per line

V

OpEqualThis 219 Return reference to *this in opera-tor= functions

SV

ParenthesesInConditional 433 Logical parts of a conditional expression shall be grouped with parentheses even if not logically required

V

ParenthesesInConditional2 434 Logical parts of a conditional expression shall be grouped with parentheses even if not logically required

V

PartialStatementDefinition 448 Do not define part of statement PV

PassByValue 303 Pass built-in types by value unless you are modifying them

V

PointerParamDereference 715 Do not pass possibly null pointers as parameters

PV

PublicInterface 203 Avoid declaring class data member to be public

I


177

User Items

RedefControlStatements 445 Do not redefine control statements PSV

RedefPrimitiveTypes 444 Do not redefine primitive types PV

RedefTypes 447 Do not redefine primitive types. Use typedef.

PV

ReferenceInitialization 720 Do not initialize a reference to an object whose address can be changed

PV

SingularSwitchStatement 745 Avoid switch statements with only one case

PV

SourceFileSize 723 Avoid source files that are longer than 500 lines

I

SourceNamingConvention 727 Use the ".c" extension for names of source files

I

SpaceInAssignmentOp 418 There shall be a single ASCII space character preceding and following assignment operators

V

SpaceInAssignmentOp2 419 There shall be a single ASCII space character preceding and following assignment operators

V

SpaceInBitwiseOp 424 There shall be a single ASCII space character preceding and following bitwise operators

V

SpaceInBitwiseOp2 425 There shall be a single ASCII space character preceding and following bitwise operators

V

SpaceInConditional 416 There shall be a single ASCII space character between a conditional statement and its opening paren-thesis

V

SpaceInConditional2 417 There shall be a maximum of 1 ASCII space character following the opening parenthesis

V

SpaceInConditionalOp 420 There shall be a single ASCII space character preceding and following conditional operators

V

SpaceInConditionalOp2 421 There shall be a single ASCII space character preceding and following conditional operators

V

SpaceInLogicalOp 423 There shall be a single ASCII space character preceding and following logical operators

V


178

User Items

SpaceInRelationalOp 422 There shall be a single ASCII space character preceding and following conditional operators

V

SpaceInRelationalOp2 422 There shall be a single ASCII space character preceding and following conditional operators

V


V


V


V


V

SpaceInSelector 431 There shall be no white space pre-ceding or following a primary opera-tor

V

SpaceInSelector2 432 There shall be no white space pre-ceding or following a primary opera-tor

V

SpacesAfterComma 428 There shall be a single ASCII space character following all commas

V

SpacesAfterSemicolon 427 There shall be a single ASCII space character following all semicolons

V

SpacesAfterUnaryOperator 430 There should be no white space between a unary operator and its operand

V

SpacesBeforeComma 426 There shall be a single ASCII space character following all commas

V

SpacesBeforeUnaryOperator 429 There shall be no white space between a unary operator and its operand

V

StatementParenthesis 439 There shall be no white spaces between the "return" or "sizeof" statements and its opening paren-thesis

V


179

User Items

StatementParenthesis2 440 There shall be no white spaces between the "return" or "sizeof" statements, arguments, or expres-sions

V

StatementParenthesis3 441 Parentheses shall be used with the "return" and "sizeof" statements

V

StructKeyword 204 Do not use the ‘struct’ keyword to declare a variable in C++

I

ThrowDestructor 215 Do not throw from within destructor V

TooManyFields 714 Avoid structs, unions, or classes with more than 20 fields

I

TrueDefinition 410 If TRUE is to be defined, & is not already defined, TRUE should be 1

I

TrueTypedef 412 If TRUE is to be defined, & is not already defined, TRUE should be 1.

I

TypeModifiersAfterType 408 Storage type modifiers shall be associated with the type, not the variable

V

TypeModifiersAfterValue 409 Storage type modifiers shall be associated with the type, not the variable

V

UnionFieldNotDefined 712 Define fields for union declarations I

UnnecessaryCast 308 Avoid unnecessary type casting V

Unnecessary Equal 304 Remove unnecessary “==true” in Boolean functions

I

UnreachableCode 744 Do not write unreachable code PV

UnreachableCode2 744 Do not write unreachable code PV

UnusedLocalVariable 311 Avoid unused local variables PV

UnusedParameter 310 Eliminate unused parameters PSV

UnusedPrivateMember 309 Eliminate unused private member variables

V

UseParenthesesInMacros 449 In a function such as macros, before multiplication or division, use parentheses

SV

UsePositiveLogic 739 Use positive logic rather than nega-tive logic whenever practical

PV


180

User Items

3264bit-32bitMultiplication.ruleDo not assign the value 32-bit multiplication to type longThis rule checks whether a 32-bit multiplication rule is assigned a long value.

Reason for rule: Bit multiplication assigned a long value may result in truncation.

Examplevoid foo() {

long longValuelongValue = 2000000 * 3000000;longValue = 2000000L * 3000000

3264bit-BinaryOverflow.ruleOperation will not resolve to 64 bitsThis rule checks whether an int is cast to a long before an operation.

Reason for rule: When operating on ints, you should at least cast one of the ints to along before the operation. Otherwise, you may have a loss of information.

Examplevoid foo() {

int a = 72int b = 55;long result = 0; result = (long)(a*b);// Violation. result = (long)((long)a*b); //Ok

}

3264bit-CastPointerToUINT.ruleDo not cast pointer to UINT typeThis rule checks whether you are casting a pointer to a UINT type

Reason for rule: In a 32-bit architecture, UINT and pointer have the same size: 32-bits. In a 64-bit architecture, UINT still has 32-bits, but pointer has size 64-bits, allowing for a possible loss if pointer is cast to UINT.

ExampleUINT foo{ char *buf; return (UINT)buf; //Violation}

181

User Items

3264bit-HardCodeValueOffset.ruleDo not use hard coded value of offset in structuresThis rule checks whether you are using the hardcoded value of offset in structures.

Reason for rule: On a 32-bit architecture, offset has 4 bytes (4*8bit=32 bit), but if the architecture is changed to 64-bit, the offset will increase to 8 bytes (*8*bit=64bit). Let compiler calculate field.

Example#include <stddef.h>#define ARCH32 true

#ifdef ARCH32#define __int3264 int //32-bit type on win32 and unix32#else //ARCH64#ifdef win64 #define __int3264 __int64 //64-bit type on win64 (warning: long on win64 is 32-bit type)#else //unix64#define __int3264 long //64-bit type on unix64 (long on unix64 is 64-bit type)#endif#endifstruct myStruct { void *ptr; int i;};

void foo() { myStruct *ps = new myStruct(); int j; ps->i = 22; j= *(int *)((unsigned __int3264)ps + sizeof(void*)); //Violation j= *(int *)((unsigned __int3264)ps + 4); //Violation j= *(int *)((unsigned __int3264)ps->i + 0); //Violation j= *(int *)((unsigned __int3264)ps + offsetof(myStruct,i)); //Ok}

182

User Items

3264bit-HardCodeValueOffset2.ruleDo not use hard coded value of offset in structuresThis rule checks whether you are using the hardcoded value of offset in structures.

Reason for rule: On a 32-bit architecture, offset has 4 bytes (4*8bit=32 bit), but if the architecture is changed to 64-bit, the offset will increase to 8 bytes (*8*bit=64bit). Let compiler calculate field.

Example#include <stddef.h>#define ARCH32 true

#ifdef ARCH32#define __int3264 int //32-bit type on win32 and unix32 #else //ARCH64 #ifdef win64#define __int3264 __int64 //64-bit type on win64 (warning: long on win64 is 32-bit type) #else //unix64 #define __int3264 long //64-bit type on unix64 (long on unix64 is 64-bit type)#endif #endif struct myStruct {

void *ptr; int i;

}; void foo() { myStruct s; int j; s.i = 22;j= *(int *)((unsigned __int3264)&s + sizeof(void*)); //Violation j= *(int *)((unsigned __int3264)&s + 4 ); //Violation j= *(int *)((unsigned __int3264)&s.i + 0 ); //Violation j= *(int *)((unsigned __int3264)&s + offsetof(myStruct,i)); //Ok }

183

User Items

3264bit-HexConstants.ruleDo not use hex constantsThis rule checks whether you are using hex constants to declare a value.

Reason for rule: You should not declare a value in hex constant because in a 32-bit architecture 0xFFFFFFFF is -1, while in a 64-bit architecture 0xFFFFFFFF is +4294967295.

Example#ifdef _WIN64 #define CONST3264(a) (a##i64) #else // unix64/32 & win32#define CONST3264(a) (a##L) #endif

void foo() {long Val1 = 0xFFFFFFFF; //Violationlong Val2 = CONST3264(-1); //Ok

}

3264bit-ImplicitTruncation.ruleAvoid writing code that will result in losing dataThis rule checks whether you use implicit truncation.

Reason for rule: Assigning a long int to an int may result in truncation when porting from 32-bit to 64-bit applications.

Examplevoid foo(){

int iVal = 72;long lVal = 6; iVal = lVal; //Violation iVal = (int)lVal; //Violation too

}

184

User Items

3264bit-ImplicitTruncation2.ruleAvoid writing code that will result in losing dataThis rule checks whether you use implicit truncation.

Reason for rule: Assigning a long int to an int may result in truncation when porting from 32-bit to 64-bit applications.

Examplevoid foo(int iVal){

long lVal ; //.. set big value for lValfoo(lVal); //Violationfoo((int)lVal); //Violation too }void foo()

}

3264bit-IntConstantToLongValue.ruleConstant assignment to long should not involve int literalsThis rule checks whether constant assignments to long involve int literals.

Reason for rule: Constant assignment to long should not involve literals because when you try to copy a 32-bit value to a 64-bit value without previous conversion (without L), it is not possible to set all 8 bytes (you can only set 4 bytes). The other 4 bytes are not set, so they may contain an accidental value.

Examplevoid foo(){

long longValue; long Value &= ~(0x00000000008000000000); // Violation: leading zeros not significant.

}

185

User Items

3264bit-IntConstantToLongValue2.ruleConstant assignment to long should not involve int literalsThis rule checks whether constant assignments to long involve int literals.

Reason for rule: Constant assignment to long should not involve literals because when you try to copy a 32-bit value to a 64-bit value without previous conversion (without L), it is not possible to set all 8 bytes (you can only set 4 bytes). The other 4 bytes are not set, so they may contain an accidental value.

Note: In the following example, the line break after longValue = should be ignored. This break is due to width restrictions on this manual page.

Examplevoid foo() {

long longValue; longValue = 0x00000000008000000000; // Violation: leading zeros not significant.

}

3264bit-IntLiteralToLongInit.ruleDo not assign literal to type longThis rule checks whether constant assignments to long involve int literals.

Reason for rule: An int literal is 32 bits in length. Assignment of int literal to long data value could lead to corruption in the upper 32 bits, or truncation if the int literal takes up more than 32 bits.

Note: In the following example, the line break after longValue = should be ignored. This break is due to width restrictions on this manual page.

Examplevoid foo() {

long longValue; longValue = 0x00000000008000000000; // Violation: leading zeros not significant.

}

186

User Items

3264bit-IntPointrCast.ruleDo not cast pointer to int typeThis rule checks whether constant assignments to long involve int literals.

Reason for rule: An int literal is 32 bits in length. Assignment of int literal to long data value could lead to corruption in the upper 32 bits, or truncation if the int literal takes up more than 32 bits.

Examplevoid foo(){

char *p;int g=(int)p; // Violation } // not significant.

}

3264bit-IntToLongPointerCast.ruleIncompatible castThis rule checks whether you cast int to long pointer cast.

Reason for rule: int and long pointer are not compatible in 64 bit, even though in 32 bit they would have been interchangeable.

Examplevoid f2005() {

int *intPointer;long *longPointer;longPointer = (long *)intPointer; // Violation

}

3264bit-LongDouble.rulePossible TruncationThis rule checks for possible truncation.

Reason for rule: Under the 32 bit platform, double can hold all significant bits. Under the 64 bit plat-form, double has 52 significant bits, and bits can be lost.

Examplevoid foo() {

double doubleValue;long longValue = 1L;doubleValue = longValue; // Violation

}

187

User Items

3264bit-LongToDoubleCast.rulePossible TruncationThis rule checks for possible truncation.


Examplevoid foo() {

long longValue = 1L; (double)longValue; // Violation

}

3264bit-LongToDoubleCast2.rulePossible TruncationThis rule checks for possible truncation.


Examplevoid moo (double) {}

void foo () {long longValue = 1L;moo(longValue); // Violation

}

3264bit-LongToIntPointerCast.ruleDo not cast long to int pointer This rule checks whether you pass long to int pointer.

Reason for rule: A pointer long should not be passed to a pointer int. It is an incompatible pass.

Examplevoid foo() {

int *intPointer;long *longPointer; intPointer = (int *)longPointer; // Violation

}

188

User Items

3264bit-LongVariableSuffixes.ruleDo not use i64 or L suffixes directlyThis rule checks whether you use i64 or L suffixes directly.

Reason for rule: Do not use i64 or L suffixes directly because it generally does not work well. Try using Macros for compatibility.

Example#ifdef _WIN64 #define CONST3264(a) (a##i64)#else#define CONST3264(a) (a##L) #endif

#define V1 0x000000000000000cL //Violation const long V2 CONST3264(3015); //Ok

3264bit-OperandCast.ruleUse explicit cast on operand of type longThis rule checks whether you use explicit cast on operands of type long.

Reason for rule: Explicit narrowing casts of type long should be used on expressions, not operands.

Examplevoid foo() {

int int1, int2, int3;long longValue; int2 = (int)longValue/int1;

// Violation: longValue is truncated to 32 bits before divide int3 = (int)(longValue/int1);

// the result of the division is truncated // to 32 bits. }

3264bit-Union.ruleAvoid union if possibleThis rule checks whether you avoid union.

Reason for rule: Unions are not portable because they are used in different ways by different sys-tems.

Exampleunion myUnion { //Violation

long l;char bytes[4];

};

189

User Items

3264bit-UsingLong.ruleAvoid using longThis rule checks whether you avoid using long.

Reason for rule: On win32/unix32/win64, long has 32-bit. On unix64, long has 64-bit. Instead of long, use your own type or specific variable definition.

Example#define ARCH32 true

#ifndef __int3264

#ifdef ARCH32#define __int3264 int //32-bit type on win32 and unix32 #else //ARCH64 #ifdef win64 #define __int3264 __int64 //64-bit type on win64 #else //unix64#define __int3264 int64_t //64-bit type on unix64 #endif#endif

#endif

long lVal; //Violation __int3264 newlVal; //Ok

3264bit-VariableDefinition.ruleDo not use a #define that the compiler cannot type checkThis rule checks whether you use a #define that the compiler cannot type check.

Reason for rule: Using a #define prevents the compiler from checking the type.

Example#define V1 20 //Violationconst int V2 = 20; //Ok #define ARCH32 true

190

User Items

3264bit-VariableDefinition2.ruleDo not use a #define that the compiler cannot type checkThis rule checks whether you use a #define that the compiler cannot type check.


Example#define V 20000L //Violation

void foo() { int i = V; // possible overflow

}


Reason for rule: Using a #define prevents the compiler from checking the type .

Example#define INDEX_STR_LEN 10#define MACHINE_NAME_LEN MAX_COMPUTERNAME_LENGTH+2 //violation



Exampledefine INDEX_STR_LEN 10 #define MACHINE_NAME_LEN 2+MAX_COMPUTERNAME_LENGTH //violation

191

User Items

ArrayElementAccess.ruleArray elements shall be accessed by the array operator [ ]This rule checks whether array elements are accessed by the array operator [].

Reason for rule: Array elements should be accessed by the array operator [] rather than the derefer-ence operator '*'. Access to array by the dereference operator '*' is cryptic and hides the real intention.

Examplevoid foo(){

int array[2]; array[1] = 0; //OK *(array+1) = 0; //Violation*array = 0; //Violation

}

AssignAllMemberVar.rule Assign to all member variables in operator= functionsThis rule checks whether you assign to all member variables in operator= functions. This rule applies only to the C++ programming language.

Reason for rule: Assigning to all member variables in operator= functions prevents data corruption.

Exampleclass Foo {public: Foo& operator=(const Foo& rhs) { if (&rhs == this) { return *this; } x = f.x; y = f.y; // violation, z is not assigned return *this; }private: int x; int y; int z;};

192

User Items

AssignCharTooHigh.ruleAvoid assigning out-of-range value to char typeThis rule checks whether constants are greater than the char type’s legal range.

Reason for rule: The range of legal values for the char type is -128 to 127.

Example/*Range of values of char type is -128 to 127.*/

void Foo(){

char c1 = 0;c1 = 145; // hit// ...return;

}

AssignCharTooLow.ruleAvoid assigning out-of-range value to char typeThis rule checks whether constants are less than the char type’s legal range.

Reason for rule: The range of legal values for char type is -128 to 127.

Example/*Range of values of char type is -128 to 127.Violation if value is less than -128.*/void Foo(){

char uVal = 0;uVal = -133; // hit// ...return;

}

193

User Items

AssignmentOperator.ruleDeclare an assignment operator for classes which have data members that are pointersThis rule checks whether you declare an assignment operator for classes with pointer member vari-ables. This rule applies only to the C++ programming language.

Reason for rule: Declaring an assignment operator for each class with pointer member variables pre-vents memory leaks and data corruption.

Note: This rule is similar to item ecpp_11.

Example// See also ECPP 11class A // Violation{public: A() {} ~A() {}private: char *cptr1;};

AssignUnCharTooHigh.ruleAvoid assigning out-of-range value to unsigned char typeThis rule checks whether constants are greater than the unsigned char type’s legal range.

Reason for rule: The range of legal values for char type is 0 to 255.

Example/*Range of values of unsigned char type is 0 to 255.Violation if assignment is too high.*/

void Foo(){

unsigned char uVal = 0;uVal = 289;// ...return;

}

194

User Items

AssignUnCharTooLow.ruleAvoid assigning out-of-range value to unsigned char typeThis rule checks whether constants are less than the unsigned char type’s legal range.

Reason for rule: The range of legal values for the char type is 0 to 255.

Example/*Range of values of unsigned char type is 0 to 255.Violation if assignment is too low.*/

void Foo(){

unsigned char uVal = 0;uVal = -1;// ...return;

}

/*

BaseDestructors.ruleMake destructors virtual for all base classesThis rule checks whether destructors in base classes are virtual. This rule applies only to the C++ pro-gramming language.

Reason for rule: Making all destructors for base classes virtual prevents memory leaks and improper object destruction.


Example// See ECPP 14

class Base{public: Base() {} ~Base() {} // Violation};

class Derived: public Base{public: Derived() {}; ~Derived() {};};

195

User Items

BitwiseInCondition.ruleDo not use the bitwise operator in conditional expressionsThis rule checks whether bitwise operators are inside conditionals.

Reason for rule: Using bitwise logical operators (&, |, or ~) in the conditional part of if, while or switch can make code difficult-to-read and error-prone.

Exampleint Foo (int iVar){

if (iVar & 0x01) { // hitiVar += 10;

} else {iVar -= 10;

}return iVar;

}

BreakInForLoop.ruleDo not use break in for loopsThis rule checks if there are breaks in your for loops.

Reason for rule: Avoiding breaks in the for loop makes your code easier to follow.


Example// Avoid break in for loop to make the code easier to follow.

void func() { for (int i = 0; i < 10; i++) { // Okay } for (int i = 0; i < 10; i++) { // Violation if (true) { break; } }}

196

User Items

CastFuncPtrToPrimPtr.ruleDo not type cast pointers to primitive types for variables that have been declared as pointers to functionsThis rule checks whether pointers to functions are cast to pointers of primitive types.

Reason for rule: Casting pointers to functions to pointers of primitive types can make code error prone.

Examplevoid Foo(char *ptrC){ *ptrC = 0; return;}void f(){ void *ptrV = 0; void (*funPtr) (char*) = 0; funPtr = &Foo; ptrV = (void*)funPtr; // violation // ... return;}

CastPointer.ruleDo not cast pointers to non-pointersThis rule checks whether you cast a pointer to a non-pointer.

Reason for rule: Casting a pointer to a non-pointer results in a loss of typechecking.

Note: This rule is enabled by default.

Examplevoid func(){ int i; char * pchar = "hello"; i = (int)pchar; // Violation}

197

User Items

CastUnsigned.ruleDo not cast an unsigned char to an unsigned intThis rule checks whether you cast an unsigned char to an unsigned int.

Reason for rule: Casting an unsigned char to an unsigned int can result in loss of precision.


Examplebool foo( char ch ){ if( (unsigned) ch == 0xFF ) { // Violation return true; } return false;}

CharacterTest.ruleUse the ctype.h facilities for character testThis rule checks whether you use the ctype.h facilities for character test.

Reason for rule: The ctype.h facilities for character tests and upper-lower conversions (isalnum, isal-pha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, isxdigit, tolower, toupper) are por-table across different character code sets, are usually very efficient, and promote international flexibility. However, other similarly named functions (such as _tolower, _toupper, _isascii) are not uni-versally portable.

Example#include

void test(char c) { if( 'a' <= c && c <= 'z') { //Violation } if( islower(c) ) { //OK } while( 'A' <= c && c <= 'Z') { //Violation } while( isupper(c) ) { //OK } }

198

User Items

CharCompareLeft.ruleDo not compare chars to constants out of char rangeThis rule checks whether you compare chars to constants out of char range

Reason for rule: Comparing chars to constants out of char range can result in a constant out of range for the comparison operator.


Exampleint foobar(char c){ if (c > 300) { return 3;} // Violation if (c > 25) { return 2;} // OK return 0;}

CharCompareRight.ruleDo not compare chars to constants out of char rangeThis rule checks whether you compare chars to constants out of char range

Reason for rule: Comparing chars to constants out of char range can result in a constant out of range for the comparison operator.


Exampleint foobar(char c){ if (c > 300) { return 3;} // Violation if (c > 25) { return 2;} // OK return 0;}

199

User Items

CommaOperator.ruleThe comma operator shall only be used in for statements and variable declarationsThis rule checks whether you use the comma operator in for statements and variable declarations.

Reason for rule: The comma operator shall only be used in for statements, variable declaration(s)/ definitions(s), and multi-statement preprocessor macro definition(s). Extensive use of the comma oper-ator reduces readability.

Examplevoid foo(int i)

{

int dVal,count; //OK

foo((dVal=i,count=dVal+1)); //Violation}

ConditionCurlyBraces.ruleAll conditional statements shall use { and } to identify the body of code associated with the conditionThis rule checks whether you use curly braces in conditional statements.

Reason for rule: Promotes readability by explicitly identifying the code block associated with a condi-tional expression. This also reduces the risk of error if a programmer must add statements to a condi-tional code block which previously had no lines of code associated with it, or perhaps had only a single line of code.

Examplevoid foo(char *str) {

/*Violation*/ if ((*str) != 0) str++;

/*Ok*/ if ((*str) != 0) { str++; }}

200

User Items

ConditionCurlyBraces2.ruleAll conditional statements shall use { and } to identify the body of code associated with the conditionThis rule checks whether you use curly braces in conditional statements.



/*Violation*/ do str++; while(*str!=0) /*Ok*/ do { str++; } while(*str!=0)}

ConditionCurlyBraces3.ruleAll conditional statements shall use { and } to identify the body of code associated with the conditionThis rule checks whether you use curly braces in conditional statements.



/*Violation*/ while ((*str) != 0) str++;

/*Ok*/ while ((*str) != 0) { str++; }}

201

User Items

ConstParam.ruleDeclare reference parameters as const references whenever possibleThis rule checks if you declared your reference parameters as const references.

Reason for rule: When your function is not going to modify the argument it is referencing, you should use const to protect variables from unintended modifications when the function returns.

Examplestruct Foo { int x; int y;};

int Bar(Foo &f) { // Violation return f.x;}

int FooBar(Foo &f) { // Okay return f.y++;}

ConstPointerFunctionCall.ruleConst data type should be used for pointers in function calls if the pointer is not to be changedThis rule checks whether you use const data types for pointers in function calls when the pointer will not be modified.

Reason for rule: The const specifier guarantees that the value of the variable cannot be changed. If the value is changed, the compiler will report an error.

Exampleint foo( int *j) { // Violation return *j;}

int bar( const int *j) { // Okay return *j;}

202

User Items

DeclareArrayMagnitude.ruleDo not declare the size of an array when the array is passed into a function as a parameterThis rule checks if you declare the magnitude of a single dimensional array in the parameters declara-tion.

Reason for rule: You should not declare the magnitude of a single dimensional array in the argument declaration. If you do, the 'C' language will pass an array argument as a pointer to the first element in the array; in fact, a different invocation of the function may pass array arguments with different magni-tudes. Therefore, specifying the magnitude of an array in a function argument definition could hinder software maintenance.

Examplevoid foo1(int ii[]) { //OK}

void foo2(int ii[30]) { //Violation}

void foo3(char a,int ii[30][30][30]) { //Violation}

void foo4(char a,int ii[][30][30]) { //OK}

DeclareBitfield.ruleDo not declare member variables as bitfieldsThis rule checks if you declare member variables as bitfields.

Reason for rule: Informational.

Examplestruct A{ int iVarBitField : 8; int iVar;};

203

User Items

DeclareExplicitConstructor.ruleDo not use the keyword 'explicit' for a constructorThis rule checks if you use the keyword ‘explicit’ for a constructor.


Exampleclass X {public: explicit X(int); explicit X(double) {}};

DeclareMutable.ruleDo not declare member variables with the 'mutable' keywordThis rule checks if you declare member variables with the 'mutable' keyword. This rule applies only to the C++ programming language.


Example/* This rule is purely informational and will report a message when a variable declaration with the 'mutable' keyword is found.*/

class Date{public: int getMonth() const; // A read-only function private:

mutable int month;int year;int day;

};

int Date::getMonth() const{

month++; // Doesn't modify anything if not mutablereturn month;

}

204

User Items

DeclareRegister.ruleDo not declare local variables with the 'register' keywordThis rule checks if you declare local variables with the 'register' keyword.


Examplevoid Foo(){ register int i = 0; // hit return;}

DeclareStaticLocal.ruleDo not declare local variables with the 'static' keywordThis rule checks if you declare local variables with the 'static' keyword.


Examplevoid Foo(){ int static iVar = 9; // hit return;}

DeclDimArray.ruleDo not declare the size of an array when the array is initializedThis rule checks if you declare the magnitude of an array declaration.

Reason for rule: When arrays are initialized in the definition, their magnitude should be set by initial-ization. By allowing the magnitude of an array to be set automatically during definition, changes to the number of elements in the initialization list do not require corresponding changes to the explicit array size.

Example#define SIZE 4

int tab1[SIZE] = {1,2,3}; //Violationint tab2[]={1,2,3}; //OKint tab3[SIZE] = {1,2,3}; //Violation

205

User Items

DefineNamingConvention.ruleAll "#define" constants shall be in uppercase This rule checks that all “#define” constants are in uppercase.

Reason for rule: This convention will make the recognition of constants easier and support future maintenance efforts.

Example#define max_value 255 /*Violation*/#define MAX_VALUE 255 /*Ok*/

DeleteIfNew.ruleWrite operator delete if you write operator newThis rule checks whether you write operator delete when you write operator new. This rule applies only to the C++ programming language.

Reason for rule: Writing operator delete and operator new in concert helps prevent memory corrup-tion and memory leaks.

Note: This rule is similar to item ecpp10.


class A{ // Violation public: A() {} void* operator new(size_t size) { return new int[size]; }};

206

User Items

DeleteNonPointer.ruleDo not call delete on non-pointersThis rule checks whether you call delete on a non-pointer.

Reason for rule: Calling delete on a non-pointer results in an invalid operand.


Exampleclass Rhino {public: Rhino(); Rhino (char *); Rhino (const char *); operator char *();};

void func(){ Rhino r; delete(r); // Violation}

DoNotUseTabs.ruleTabs that do not use ASCII spaces should not be usedThis rule checks whether you are using only ASCII white spaces as tabs.

Reason for rule: Different operating systems, display devices, and editors handle tabs in different ways. Code containing tabs will likely be indented incorrectly if ported to another environment.

Examplevoid foo(){

int i; /*Violation*/ int j; /*Ok*/}

207

User Items

DoWhile.rulePrefer while statements over do statementsThis rule checks whether your code prefers while statements over do statements.

Reason for rule: Using do statements can lead to errors and confusion. Using while statements instead of do statements can make code clearer and help prevent errors.


Exampledo { i++;} while ( i < 10); // Violation

while (i < 10) { // OK i++;}

EnumKeyword.ruleDo not use the ‘enum’ keyword to declare a variable in C++This rule checks whether your C++ code uses enum keywords to declare variables. This rule applies only to the C++ programming language.

Reason for rule: Readability.

Example// enum keyword is unnecessary in C++ when declaring a variable.enum Colors { RED, BLUE, GREEN };enum Colors c; // Violation, enum keyword is unnecessaryColors C; // OK

208

User Items

EnumNamingConvention.ruleIn an enumerated list, list members (elements) shall be in uppercase and names or tags for the list shall be in lowercaseThis rule checks naming conventions in enumerated lists; it checks that list members (elements) are in uppercase and that tags for the list are in lowercase.

Reason for rule: The members of a list are equivalent to a defined constant; only the compiler is per-forming the definition.

Example//OKenum color { RED, BLUE, GREEN};//Violationenum Color { red, blue, green};

EOSDefinition.ruleIncorrect End-Of-String (EOS) definitionThis rule check whether you are using EOS to terminate a string.

Reason for rule: EOS should be used to terminate a string rather than NULL, since NULL is not guar-anteed to be defined as zero. This also promotes the use of defined constants rather than hard coded values.

Example#define EOS 0 /*Violation*/#undef EOS#define EOS NULL /*Violation*/#undef EOS#define EOS '\0' /*Ok*/

209

User Items

EOSUsage.ruleEOS shall be used to terminate a string rather than using backslash-zero '\0' This rule checks that EOS is used to terminate a string.

Reason for rule: EOS should be used to terminate a string rather than NULL, since NULL is not guar-anteed to be defined as zero. This also promotes the use of defined constants rather than hard coded values.

Example#define EOS '\0';

void foo() {

char str[30] = "Sample text.";str[7] = '\0'; /*Violation*/

str[7] = EOS; /*OK*/}

EqualityFloatLeft.ruleDo not check floats for equality; check for greater than or less thanThis rule checks whether you check floats for equality instead of checking for greater than or less than.

Reason for rule: If you check floats for equality, you make your code more susceptible to rounding errors.


Examplevoid func(float a, float b){ if (a==b) { } // Violation while (a!=b) { } // Violation if (a>b) { } // OK}

210

User Items

EqualityFloatRight.ruleDo not check floats for equality; check for greater than or less thanThis rule checks whether you check floats for equality instead of checking for greater than or less than.

Reason for rule: If you check floats for equality, you make your code more susceptible to rounding errors.


Examplevoid func(float a, float b){ if (a==b) { } // Violation while (a!=b) { } // Violation if (a>b) { } // OK}

ExplicitEnumValues.ruleWhen using enum, the values of each member should be explicitly declaredThis rule checks if the values of each member are explicitly declared when you are using enum.

Reason for rule: Declaring values is useful as a documenting feature. Documenting is valuable when using an emulator, logic analyzer, or other debugging device.

Exampleenum my_enum { a, //Violation b = 3 //OK};

ExplicitLogicalTest.ruleUse explicit logical tests in conditional expressionsThis rule checks whether you use explicit logical tests in conditional expressions.

Reason for rule: Using explicit logical tests in conditional expressions improves code readability.

Examplevoid foo( int *j){ if(!j){ // Violation } if(j == 0){ // OK }}

211

User Items

ExplicitLogicalTests.ruleAn explicit logical comparison should be used in conditional expressionThis rule checks that explicit logical tests are used in conditional expressions.

Reason for rule: Using explicit logical tests in conditional expressions improves code readability.

Examplevoid foo() { int isvisible = 1; if (isvisible) /*Violation*/ { ; } if (isvisible == 1) /*Ok*/ { ; } if (!isvisible) /*Violation*/ { ; } if (isvisible != 1) /*Ok*/ { ; }}

ExprInSizeof.ruleAvoid passing expressions like assignment to sizeof() operatorsThis rule checks for expressions in the sizeof operator.

Reason for rule: Expressions in the sizeof operator will not be executed.

Examplevoid foo (){ int iVar1 = 0; int iVar2 = 0; iVar1 = sizeof(iVar2 = 1); /* Violation */

return;}

212

User Items

FalseDefinition.ruleIf FALSE is to be defined, and is not already defined, FALSE should be 0This rule checks whether you defined FALSE as 0.

Reason for rule: Any other use of FALSE is misleading and will not be guaranteed to work predictably.

Example#define FALSE 1 /*Violation*/#undef FALSE#define FALSE /*Violation*/#undef FALSE#define FALSE 0 /*Ok*/

FalseTypedef.ruleIf FALSE is to be defined, and is not already defined, FALSE should be 0This rule checks if FALSE is defined as 0.

Reason for rule: Any other use of Fxsave falsetypedef.fmALSE is misleading and will not be guaran-teed to work predictably.

Example#ifndef TRUEtypedef enum { FALSE = 0,TRUE = 3 /*Violation*/} BOOL ;#endif

FileNameConvention.ruleUse lowercase for file namesThis rule checks whether your file names are in lowercase.

Reason for rule: When an entire development group agrees on a common convention, code becomes easier to read and more easily understood.

213

User Items

ForLoopVarAssign.ruleDo not assign to loop control variables in the body of a for loopThis rule checks whether you assign to loop control variables in the body of a for loop.

Reason for rule: For loop control variables should only be modified in the initialization and condition expressions of the for loop statement. Modifying them inside the body of the for loop makes the loop condition difficult to understand and points to a possible logical flaw in the code.

Examplevoid func() { for (int i = 0; i < 100; i++) { // Violation i += 3; } for (int i = 0; i < 100; i++) { // Violation i++; }}

FractionLoss.ruleDo not assign the dividend of two ints to a floatThis rule checks whether you assign the dividend of two ints to a float.

Reason for rule: Assigning a dividend of two ints to a float may cause a loss of fraction.


Examplevoid func(){ int a = 3; int b = 4; double d; d = a / b; // Violation d = ((double)a) / b; // OK}

214

User Items

FuncModifyGlobalVar.ruleAvoid functions that modify the global variableThis rule checks whether functions modify the global variable.


Exampleint theGlob;// ...void foo( int iVar ){ theGlob = -1; if (iVar == 0 )

{ theGlob = 0; } else { theGlob = 1; } return;}

FunctionCurlyBraces.ruleAll curly braces "{ }" shall appear on a line by themselvesThis rule checks that curly braces “{}” appear on a line by themselves.

Reason for rule: This rule promotes readability by clearly indicating the beginning and end points of a block of code. This also encourages block commenting.

Example#define true 1#define false 0

void foo() { int bVal = 1;

while ( bVal ) { bVal = false; /*Ok*/ } while ( bVal ) { bVal = false; /*Violation*/ } }

215

User Items

FunctionCurlyBraces2.ruleAll curly braces "{ }" shall appear on a line by themselvesThis rule checks that curly braces “{}” appear on a line by themselves.

Reason for rule: This rule promotes readability by clearly indicating the beginning and end points of a block of code. This also encourages block commenting.


void foo() { int bVal = 1;

while ( bVal ) { bVal = false; /*Ok*/ } while ( bVal ) { bVal = false; } /* Violation */

}

FunctionSize.ruleAvoid functions with over 50 linesThis rule checks whether functions have over 50 lines.

Reason for rule: Programs should be designed so that most of the functions will be less than 50 lines of source listening. Algorithms are easier to create and to understand if they are built of pieces small enough to be grasped as one concept.

216

User Items

GlobalPrefixExclude.ruleGlobal prefixes should only be used for global variablesThis rule checks whether global prefixes are used with local variables.

Reason for rule: Using global prefixes for local variables reduces code readability.

Examplevoid foo(){ int theVar = 0; // ... theVar++; return; }

GlobalVarFound.ruleAvoid global variablesThis rule checks whether your code contains global variables.


Exampleint theVar; // hit// ...void foo(int iVar){ theVar = iVar; return; }

217

User Items

HardCodeValue.rule"#define" or enum constants should be used instead of hard coded values whenever possibleThis rule checks whether you are avoiding using hard coded values.

Reason for rule: Using #define or enum constants rather than hard coded values promotes the main-tainability of 'C' code by creating a localized area for changes.

Example#define buff 256#define OK 1

enum color{ RED = 0, BLUE = 1, GREEN = 2 /*...*/};

void foo() { int tabColorsNew[256]; /*Violation*/ int tabColors[buff]; /*Ok*/

if ( tabColors[0] == 1 ) /*Violation*/ { /*...*/ }

if ( tabColors[RED] == OK ) /*Ok*/ { /*...*/ } }

218

User Items

HardCodeValueWithZero.rule"#define" or enum constants should be used instead of hard coded values whenever possibleThis rule checks whether you are avoiding using hard coded values.

Reason for rule: Using #define or enum constants rather than hard coded values promotes the main-tainability of 'C' code by creating a localized area for changes.

Example/* NOTE: This rule expands rule HardCodeValue.rule about case Zero. */

#define buff 256#define OK 0



if ( tabColors[0] == 0 ) /*Violation*/ { /*...*/ }


HeaderInitialization.ruleHeaders should not contain any initializationThis rule checks whether headers contain any initialization.

Reason for rule: Headers should not contain any initialization. When initialization is in the header, it is not clear which function "owns" the date (that is, the "defining instance" is not localized). Multiple source files each including a file containing initializations will generally produce "multiply defined" diag-nostics.

219

User Items

IfAssign.ruleAvoid assignment in if statement conditionThis rule checks whether your code has assignment within an if statement condition.

Reason for rule: Legibility and maintainability. Assignment in the context of an if statement is easily confused with equality.


Example// Assignment in the context of if statement is easily// confused with equality.void foo(int a, int b) { if ( a = b ) {} // Violation if ( a == b ) {} // OK}

IfElse.ruleAll if statements should have an else clauseThis rule checks if each of your if statements has an else clause.

Reason for rule: Writing if and else in concert improves readability and reliability.

Examplevoid Foo(bool b) { int i = 0; int j = 0; if (b) { // Informational, should have an else clause i += j; } if (b) { j += i; } else { // Okay, has an else clause i++; }}

220

User Items

ImplicitUnsignedInit.ruleDo not initialize unsigned integer variables with signed constantsThis rule checks if you initialize unsigned integer variables with signed constants.

Reason for rule: Numeric constants have a type. Use the appropriate suffix to avoid undesirable implicit cast.

Examplevoid foo(){ unsigned int x = 21; /* Violation */ unsigned int y = -21; /* Violation */ unsigned int z = 21u; /* OK */

return;}

InitCharOutOfRange.ruleAvoid assigning out-of-range value to char typeThis rule checks for constants out of the legal range for the char type.

Reason for rule: The legal range of values of char type is -128 to 127.

Examplevoid Foo(){ char uVal = 157; // hit // ... return;}

InitPointerVar.ruleInitialize all pointer variablesThis rule checks if all of your pointer variables are initialized.

Reason for rule: Initializing pointer variables prevents dereferencing of uninitialized pointers.

Examplevoid foo() { int *i; // Violation int *k = 0; // Okay}

221

User Items

InitUnCharOutOfRange.ruleAvoid assigning out-of-range value to unsigned char typeThis rule checks for constants out of the legal range for the unsigned char type.

Reason for rule: The legal range of values of the unsigned char type is 0 to 255.

Examplevoid Foo(){ unsigned char uVal = 259; // hit // ... return;}

LineLength.rulePhysical lines shall be less than eighty charactersThis rule checks that physical lines are less than eighty characters.

Reason for rule: This rule promotes readability across various editors. Additionally, some printers will not print columns greater than 80 columns.

LocalVariableNames.ruleLocal variable names shall be lowercaseThis rule checks whether local variable names are proper lowercase.

Reason for rule: By standardizing the appearance of variables, you can more easily differentiate user-defined variables from constants.

Examplevoid foo() { int Count; //Violation int date; //OK};

222

User Items

LongConst.ruleUse capital 'L' instead of lowercase 'l' to indicate longThis rule checks whether you use capital “L” instead of lowercase ‘l’ to indicate long.

Reason for rule: Using capital “L’ to indicate long increases readability and correctness.


Examplevoid func(){ int i = 0; i = 341; // OK i = 34l; // Violation i = 34L; // OK}

MacroSize.ruleThe length of a macro should not exceed 10 linesThis rule checks whether the length of a macro exceeds 10 lines.

Reason for rule: Macros over 10 lines are hard to read.

Example/*Violation*/#define SUM(\ PARAMETER_1,\ PARAMETER_2,\ PARAMETER_3,\ PARAMETER_4)\ (\ PARAMETER_1+\ PARAMETER_2+\ PARAMETER_3+\ PARAMETER_4\ )void main(){ int val = SUM(1,1,1,1);

}

223

User Items

MacroWithinInclude.ruleDo not use macros in the include statement This rule checks that macros are not used in the include statement.

Reason for rule: Including header files with “#define” predefined makes code hard to read and under-stand.

Example#define HEADER_FILE(nr) "myHeader" #nr ".h"#include HEADER_FILE(12) /*Violation*/

ManyCases.ruleAvoid switch statements with many casesThis rule checks whether your code contains switch statements with many cases.

Reason for rule: Using many case statements makes code difficult to follow. More importantly, switches with many cases often indicate places where polymorphic behavior could better be used to provide different behavior for different types. Note that although the general principle is to avoid many cases in a switch, the actual cutoff point is arbitrary.

Examplevoid foo(int i) { switch (i) { // Violation case 1: break; case 2: break; case 3: break; case 4: break; case 5: break; case 6: break; case 7: break; case 8: break; case 9: break; case 10: break; case 11: break; default: break; }}

224

User Items

MetricBlockofCode.ruleNumber of blocks of code per functionThis metric measures the number of blocks of code in a function. This rule applies only to the C++ pro-gramming language.

Reason for rule: “Code with many paths will be harder to understand and more likely to contain errors” (A Practical Guide to Object-Oriented Metrics by Mark Schroeder, IT Professional, November/Decem-ber 1999, pg. 34).

Examplevoid func(int i} { if (1) { // do something; } else { // do another; } do { } while(1); switch(i) { case 1: break; default: break; }}

MetricBreakEncap.ruleAvoid using global in member functionsThis metric measures the number of global variables referenced in your code’s member functions. This rule applies only to the C++ programming language.

Reason for rule: “Global references tend to break encapsulation and inhibit reuse. While global refer-ences may be difficult to eliminate entirely, they should be used as sparingly as possible.” (A Practical Guide to Object-Oriented Metrics by Mark Schroeder, IT Professional, November/December 1999, pg. 33).

Exampleint globalVar = 1;class Foo {public: void func() { memberVar = GlobalVar; // Violation, global var is used here }private: int memberVar;};

225

User Items

MetricFuncCall.ruleNumber of function callsThis metric measures the number of function calls in each function. This rule applies only to the C++ programming language.

Reason for rule: “TFC [Total Function Calls] tallies the number of calls to methods and system func-tions within the system, class, or method. This metric measures size in a way that is more independent of coding style than the LOC [Lines Of Code] metric.” (A Practical Guide to Object-Oriented Metrics by Mark Schroeder, IT Professional, November/December 1999, pg. 32).

Exampleclass Base {};class Dev1 : public Base {};class Dev2 : public Dev1 {};

MetricInheritance.ruleClass inheritance levelThis metric measures the class inheritance level by calculating the number of base classes. This rule applies only to the C++ programming language.

Reason for rule: “An unnecessarily deep class hierarchy adds to complexity and can represent a poor use of the inheritance mechanism.” (A Practical Guide to Object-Oriented Metrics by Mark Schroeder, IT Professional, November/December 1999, pg. 33).

Exampleclass Base {};class Dev1 : public Base {};class Dev2 : public Dev1 {};

226

User Items

MetricMembers.ruleNumber of data member(s) per classThis metric measures the number of data members per class. This rule applies only to the C++ pro-gramming language.

Reason for rule: “The number of attributes in a class indicates the amount of data the class must maintain in order to carry out its responsibilities.” (A Practical Guide to Object-Oriented Metrics by Mark Schroeder, IT Professional, November/December 1999, pg. 33).

Exampleclass Foo {public: int i;protected: int j;private: int k;};

MetricMethod.ruleNumber of method(s) per classThis metric measures the number of methods per class. This rule applies only to the C++ programming language.

Reason for rule: “The number of methods per class indicates the total level of functionality imple-mented by a class.” (A Practical Guide to Object-Oriented Metrics by Mark Schroeder, IT Professional, November/December 1999, pg. 33).

Exampleclass Foo {public: void method1();protected: void method2();private: void method3();};

227

User Items

MetricParam.ruleNumber of parameter(s) per methodThis metric measures the number of parameters in each method. This rule applies only to the C++ pro-gramming language.

Reason for rule: “A high number of parameters indicates a complex interface to calling objects, and should be avoided.” (A Practical Guide to Object-Oriented Metrics by Mark Schroeder, IT Professional, November/December 1999, pg. 34).

Exampleclass Foo {public: // Violation so many parameters void func(int i, double d, float f, char c, Foo &);};

MetricPrivateMembers.ruleNumber of private data member(s) per classThis metric measures the number of private data members per class. This rule applies only to the C++ programming language.


Exampleclass Foo {private: int k;};

MetricPrivateMethod.ruleNumber of private methods per classThis metric measures the number of private methods per class. This rule applies only to the C++ pro-gramming language.


Exampleclass Foo {private: void method();};

228

User Items

MetricProtectedMembers.ruleNumber of protect data member(s) per classThis metric measures the number of protected data members per class. This rule applies only to the C++ programming language.


Exampleclass Foo {protected: int j;};

MetricProtectedMethod.ruleNumber of protected method(s) per classThis metric measures the number of protected methods per class. This rule applies only to the C++ programming language.


Exampleclass Foo {protected: void method();};

MetricPublicMembers.ruleNumber of public data member(s) per classThis metric measures the number of public data members per class. This rule applies only to the C++ programming language.


Exampleclass Foo {public: int i;};

229

User Items

MetricPublicMethod.ruleNumber of public method(s) per classThis metric measures the number of public methods per class. This rule applies only to the C++ pro-gramming language.


Exampleclass Foo {public: void method();};

ModifyInCondition.ruleDo not use operator ++ or -- in the conditional expression of if, while, or switchThis rule checks whether you use operator ++ or -- in the conditional part of if, while, or switch.

Reason for rule: Using the operator ++ or -- in the conditional part of if, while, or switch can make code difficult to read and error prone.

Exampleint Foo (int iVar){ if (iVar-- && iVar<10) { // hit iVar += 10; } else { iVar -= 10; } return iVar;}

230

User Items

NameBool.ruleBegin all boolean type variables with 'b'This rule checks whether all of your boolean type variables begin with ‘b’.

Reason for rule: Hungarian notation. When an entire development group agrees on a common con-vention, code becomes easier to read and understand.

Examplevoid foo() { bool Var; // Violation bool bVar; // OK}

NameClass.ruleBegin class names with an uppercase letterThis rule checks whether each class name begins with an uppercase letter. This rule applies only to the C++ programming language.

Reason for rule: When an entire development group agrees on a common convention, code becomes easier to read and understand.

Exampleclass foo {}; // Violationclass Foo {}; // OK

231

User Items

NameConflict.ruleAvoid internal or external name conflictThis rule checks for internal or external name conflict. This rule applies only to the C programming lan-guage.

Reason for rule: Internal or external name conflicts with a C++ reserved word will cause problems if the program is compiled with a C compiler. Most C compilers do not detect naming conflicts, so name conflicts can can lead to unpredictable program behavior.

Exampleint bool = 0;int catch = 0;int class = 0;int const_cast = 0;int delete = 0;int dynamic_cast = 0;int explicit = 0;int export = 0;int false = 0;int friend = 0;int inline = 0;int mutable = 0;int namespace = 0;int new = 0;int operator = 0;int private = 0;int public = 0;int protected = 0;int reinterpret_cast = 0;int static_cast = 0;int template = 0;int this = 0;int throw = 0;int true = 0;int try = 0;int typeid = 0;int typename = 0;int using = 0;int virtual = 0;int wchar_t = 0;

232

User Items

NameConstantVar.ruleBegin constant variables with ‘c’This rule checks whether each constant variable begins with ‘c’.


Example// Constant variable names begin with 'c'const int Foo = 0; // Violationconst int cFoo = 0; // OK

NameDataMember.ruleBegin class data member names with ‘its’This rule checks if your class data member names begin with ‘its’. This rule applies only to the C++ pro-gramming language.


Exampleclass Foo {private: int bar; // Violation int itsBar // OK};

NameDouble.ruleBegin all double type variable with 'd'This rule checks whether all of your double type variables begin with ‘d’.


Examplevoid foo() { double Var; // Violation double dVar; // OK}

233

User Items

NameEnumType.ruleEnumerated type name shall begin with an uppercase letter prefixed by the software element and suffixed by ‘_t’This rule checks whether the name of each enumerated type begins with an uppercase letter, is pre-fixed by the software element, and is suffixed by '_t' .


Example// The names of abstract data types shall begin with// an uppercase, prefixed by software element and // suffixed by // '_t'.

enum LOC_PossibleColors_t { RED, BLUE, GREEN }; // OK

enum LOC_PossibleColors { RED, BLUE, GREEN }; // Violation

NameFloat.ruleBegin all float type variables with 'f'This rule checks whether all of your float type variables begin with ‘f’.


Examplevoid foo() { float Var; // Violation float fVar; // OK}

NameFunction.ruleBegin function names with uppercase letterThis rule checks whether each function name begins with an uppercase letter.


Examplevoid foo(); // Violationvoid Foo(); // OK

234

User Items

NameGlobalVar.ruleBegin global variable names with ‘the’This rule checks whether each global variable name begins with “the”.


Exampleint global_var; // Violationint theWindows; // OK

NameInt.ruleBegin all integer type variable with 'i'This rule checks whether all of your integer type variables begin with ‘i’.


Examplevoid foo() { int Var; // Violation int iVar; // OK}

NameIsFunction.rule'is' functions should return bool valuesThis rule checks if your ‘is’ function names begin with bool values.

Reason for rule: Beginning ‘is’ function names with bool values improves legibility and clarifies what the return value means.

Exampleint isPos(int x) { // Violation return x > 0;}

bool isPositive(int x) { // Okay return x > 0;}

235

User Items

NameLongInt.ruleBegin all long integer variables with 'li'This rule checks whether all of your long integer variables begin with ‘li’.


Examplevoid foo() { long int Var; // Violation long int liVar; // OK}

NamePointerVar.rulePrefix a variable type 'pointer' with a 'p' characterThis rule checks if your variable type pointer names begin with ‘p’.

Reason for rule: The legibility of code is better, and bugs can be avoided, by adding a prefix of a type to a variable

Exampleint *Foo; // Violationint *pFoo; // OK

NameShortInt.ruleBegin all short integer variables with 'si'This rule checks whether all of your short integer variables begin with ‘si’.


Examplevoid foo() { short int Var; // Violation short int siVar; // OK short Violation; // Violation short siOkay; // OK}

236

User Items

NameSignedChar.ruleBegin all signed character variables with 'c'This rule checks whether all of your signed character variables begin with ‘c’.


Examplevoid foo() { unsigned char Var; // Violation unsigned char ucVar; // OK}

NameString.ruleBegin all terminated characters string variables with 'sz'This rule checks whether all of your terminated characters’ string variables begin with ‘sz’.


Examplevoid foo() { char Var[] = "\n"; // Violation char szVar[] = "\n"; // OK}

}

NameStructType.ruleStruct type name shall begin with an uppercase letter prefixed by software element and suffixed by '_t'This rule checks the prefixes, suffixes, and first letters of your struct type names.


Examplestruct LOC_Position { }; // Violationstruct LOC_Position_t {} // OK

237

User Items

NameUnsignedChar.ruleBegin all unsigned character type variables with 'uc'This rule checks whether all of your unsigned character type variables begin with ‘uc’.


Examplevoid foo() { unsigned char Var; // Violation unsigned char ucVar; // OK}

NameUnsignedInt.ruleBegin all unsigned integer type variables with ‘ui’This rule checks whether all of your unsigned integer type variables begin with ‘ui’.


Examplevoid foo() { unsigned int Var; // Violation unsigned int uiVar; // OK}

NameVariable.ruleBegin all variables with a lowercase letterThis rule checks if your variable names begin with a lowercase letter.


Examplevoid foo() { int Local_var; // Violation int local; // OK}

238

User Items

NamingStructUnionMembers.ruleUse lowercase letters for structure and union member namesThis rule checks whether you use lowercase letters for structure and union member names.

Reason for rule: Using lowercase letters for structure and union member names will make it easier to recognize structure/union members.

Example//OKstruct date_foo1 { int dateMonth; int dateDay; int dateYear;};

//Violationstruct date_foo2 { int datemonth; int DateDay; int Dateyear; };

NoInputParamsInMacros.ruleNo input parameters in macrosThis rule checks whether a function like macros has parameters.

Reason for rule: Without parameters a function like macros may work in unpredicable ways.

Example#define A_PLUS_B (a+b) /*Violation*/

NonScalarTypedefs.ruleAppend names of non-scalar typedefs with "_t".Reason for rule: Following this convention will make it easier to recognize user-defined data types and maintain the software. This rule applies only to the C++ programming language.

Exampleclass MyClass { int count;};

typedef MyClass My_t; //OKtypedef MyClass My; //Violation

239

User Items

NullDefinition.ruleIncorrect NULL definitionThis rule checks whether your definition of void is (void *)0.

Reason for rule: Any other usage of NULL is misleading and error prone.

Example#define NULL 0 /*Violation*/#undef NULL#define NULL /*Violation*/#undef NULL#define NULL (void*)0 /*OK*/

NumberFunctionParam.ruleAvoid functions with more than 5 parametersThis rule checks for functions with more than 5 parameters.

Reason for rule: Avoiding functions with more than 5 parameters will reduce the amount of coupling between functions. If more parameters are needed, a structure could be used to hold related data and a pointer could be passed.

Examplevoid foo(int a, int b, int c, int d, int e, int f) // Violation{ }

NumberMacroParams.ruleMacros should not use more than 5 parametersThis rule checks that macros do not use more than 5 parameters.

Reason for rule: If a large number of parameters are passed to a macro, it may become hard to read and understand. If this occurs, it may be beneficial to break the macro down into multiple macros or make it into a function.

Example#define PLUS(a,b,c,d,e,f) (a+b+c+d+e+f) /*Violation*/

240

User Items

OneStatementPerLine.ruleOnly one statement shall be allowed per lineThis rule checks that there is only one statement per line.

Reason for rule: This rule promotes readability and maintainability by reducing code complexity.

Examplevoid foo(){ int i; char c; /*Violation*/

int ii; /*OK*/ char cc; }

OpEqualThis.ruleReturn reference to *this in operator= functionsThis rule checks whether you return reference to *this in operator= functions. This rule applies only to the C++ programming language.

Reason for rule: Returning reference to *this in operator= functions protects you from not know-ing where the temporary gets destroyed and allows you to declare the operator='s parameter as a reference to const, which is safer than just declaring it to be a reference.



class A{public: explicit A(int i = 0) : _i(i) {} void operator=(const A& a) // violation { if (&a == this) { return; } int _i = a._i; return; }private: int _i;};

241

User Items

ParenthesesInConditional.ruleLogical parts of a conditional expression shall be grouped with parentheses even if not logically requiredThis rule checks whether you are using your parentheses in logical expressions.

Reason for rule: This promotes readability by explicitly indicating the logical groups being compared.

Examplevoid foo() { int x = 1; int y = 1;

if ((x == 0) || (y == 0)) /*Ok*/{}if (x == 0 || y == 0) /*Violation*/{}}

ParenthesesInConditional2.ruleLogical parts of a conditional expression shall be grouped with parentheses even if not logically requiredThis rule checks whether you are using your parentheses in logical expressions.

Reason for rule: This promotes readability by explicitly indicating the logical groups being compared.

Examplevoid foo() {

int x = 1;int y = 1;

if ((x == 0) && (y == 0)) /*Ok*/{}if (x == 0 && y == 0) /*Violation*/{}

}

242

User Items

PartialStatementDefinition.ruleDo not define part of statementThis rule checks whether you are defining part of a statement.

Reason for rule: Defining a part of a statement makes code unreadable and is extremely error prone.

Example#define PARTIAL(a) ((a) * /*Violation*/

PassByValue.rulePass built-in types by value unless you are modifying themThis rule checks if your code passes arguments of built-in types by value, unless they should be modi-fied by functions.

Reason for rule: Passing arguments of built-in types by value improves the efficiency of your code.

Exampleint Foo(int i, int &j) { // Violation return i + j;}

int Bar(int i, int &j) { // Okay j += i; return j;}

243

User Items

PointerParamDereference.ruleDo not pass possibly null pointers as parametersThis rule checks if you dereference possibly null pointer parameters.

Dereferences of possibly null pointers may be protected by conditional statements or assertions that check that the pointer is not NULL. This rule reports all functions which are passed pointers.

Reason for rule: A dereferenced null pointer is a common cause of program failures.

Examplevoid Foo (int *ptr1, char *ptr2, float *ptrF)

{

*ptr1 = 10; // possibly null pointer dereference

ptr2 = 0;

if( ptrF==0) {

return;

}

*ptrF = 0; // OK

return;}

PublicInterface.ruleAvoid declaring class data member to be publicThis rule checks whether the public interface of your code contains member variables. This rule applies only to the C++ programming language.

Reason for rule: Legibility and maintainability.

Exampleclass Foo { public: int i; // Violation};class Foo {private: int i; // OK};

244

User Items

RedefControlStatements.ruleDo not redefine control statementsThis rule checks whether you are redefining control statements.

Reason for rule: Redefining control statements may cause unpredictable results.

Example#define if while /*Violation*/#define for if /*Violation*/#define else try /*Violation*/

RedefPrimitiveTypes.ruleDo not redefine primitive typesThis rule checks whether you are redefining primitive types.

Reason for rule: This increases code readability by avoiding the creation of new unnecessary types.

Example#define T30 char /* Complain */#define T31 unsigned char /* OK */

RedefTypes.ruleDo not redefine primitive types. Use typedef.This rule checks whether you are using typedef instead of “#define.”

Reason for rule: Some compilers could have predefined types (INT, VOID). Using typedef instead of “#define”' guarantees that you will not redefine it.

Example#define INT int /*Violation*/

245

User Items

ReferenceInitialization.ruleDo not initialize a reference to an object whose address can be changedThis rule checks whether you initialize a reference to refer to an object whose address can be changed. This rule applies only to the C++ programming language.

Reason for rule: The reference to an object in the free store can be deleted via a pointer, and conse-quently can refer to an object with a null address.

Examplevoid foo(){ int *ptr = 0;

int &rptr = *ptr; //Violation // assignment through null rptr = 10;}

SingularSwitchStatement.ruleAvoid switch statements with only one caseThis rule checks for switch statements with only one case statement.

Reason for rule: switch statements with only one case statement could be described using an if statement.

Examplevoid foo (){ int i = 0; /* ... */ switch(i) /* Violation */ { case 0: break; default: break; }

return;}

246

User Items

SourceFileSize.ruleAvoid source files that are longer than 500 linesThis rule checks for source files that are longer than 500 lines.

Reason for rule: Larger files are more difficult to edit and maintain than smaller files.

SourceNamingConvention.ruleUse the ".c" extension for names of source filesThis rule checks whether C source files use the “.c” extension.

Reason for rule: This convention is common practice and is mandated by some compilers.

SpaceInAssignmentOp.ruleThere shall be a single ASCII space character preceding and following assignment operatorsThis rule checks whether there is a single ASCII space character preceding and following assignment operators.

Reason for rule: This convention promotes readability by clearly separating the operands from the operator.

Exampleint x = 1; /*Ok*/int y = 1; /*Violation*/int z=1; /*Violation*/

SpaceInAssignmentOp2.ruleThere shall be a single ASCII space character preceding and following assignment operatorsThis rule checks whether there is a single ASCII space character preceding and following assignment operators.


Exampleint x = 1; /*Ok*/int y = 1; /*Violation*/int z=1; /*Violation*/

247

User Items

SpaceInBitwiseOp.ruleThere shall be a single ASCII space character preceding and following bitwise operators This rule checks whether there is a single ASCII space character preceding and following bitwise oper-ators.


Examplevoid foo() { int z = 73; int y=0; y=z | 0x0f; /*Ok*/ y=z|0x0f; /*Violation*/ y=z | 0x0f; /*Violation*/}

SpaceInBitwiseOp2.ruleThere shall be a single ASCII space character preceding and following bitwise operators This rule checks whether there is a single ASCII space character preceding and following bitwise oper-ators.


Examplevoid foo() { int z = 73; int y=0; y=z | 0x0f; /*Ok*/ y=z|0x0f; /*Violation*/ y=z | 0x0f; /*Violation*/}

248

User Items

SpaceInConditional.ruleThere shall be a single ASCII space character between a conditional statement and its opening parenthesisThis rule checks whether there is a single space ASCII space character between a conditional state-ment and its opening parenthesis.

Reason for rule: This promotes readability by providing a clear indication that a statement is a condi-tional statement versus a function, and by providing a clear break between the conditional keyword and its associated expression.

Examplevoid foo(){ int x=1; int y=1; if (x == y) /*Ok*/ { }

while(x == y) /*Violation*/ { }}

249

User Items

SpaceInConditional2.ruleThere shall be a maximum of 1 ASCII space character following the opening parenthesisThis rule checks whether there is a maximum of 1 ASCII space character following the opening paren-thesis.

Reason for rule: A maximum of 1 ASCII space after the opening parenthesis improves readability.

Examplevoid foo(){ int x=1; int y=1;

if (x == y) /*Ok*/ { }

if ( x == y ) /*Ok*/ { } if( x == y ) /*Violation*/ { }}

SpaceInConditionalOp.ruleThere shall be a single ASCII space character preceding and following conditional operatorsThis rule checks that there is a single ASCII space character preceding and following conditional oper-ators.


Examplevoid foo() {int j=10;int i=1;

j = ( i < 0 ) ? ( -i ) : ( i ); /*Violation*/j = ( i < 0 )?( -i ) : ( i ); /*Violation*/j = ( i < 0 ) ? ( -i ) : ( i ); /*Ok*/

}

250

User Items

SpaceInConditionalOp2.ruleThere shall be a single ASCII space character preceding and following conditional operatorsThis rule checks whether there is a single ASCII space character preceding and following conditional operators.


Examplevoid foo() {int j=10;int i=1;

j = ( i < 0 ) ? ( -i ) : ( i ); /*Violation*/j = ( i < 0 )?( -i ) : ( i ); /*Violation*/j = ( i < 0 ) ? ( -i ) : ( i ); /*Ok*/

}

SpaceInLogicalOp.ruleThere shall be a single ASCII space character preceding and following logical operators This rule checks whether there is a single ASCII space character preceding and following logical oper-ators.


Examplevoid foo() { int x = 1; int y = 1;

if(x || y) /*OK*/ { } if(x||y) /*Violation*/ { }

if(x || y) /*Violation*/ { }}

251

User Items

SpaceInRelationalOp.ruleThere shall be a single ASCII space character preceding and following conditional operatorsThis rule checks whether there is a single ASCII space character preceding and following conditional operators.


Examplevoid foo() {

int x = 1;

if(x == 1) /*OK*/ { }

if(x==1) /*Violation*/ { } if(x == 1) /*Violation*/ { }

}

252

User Items

SpaceInRelationalOp2.ruleThere shall be a single ASCII space character preceding and following conditional operatorsThis rule checks whether there is a single ASCII space character preceding and following conditional operators.


Examplevoid foo() {

int x = 1;

if(x != 1) /*OK*/ { }

if(x!=1) /*Violation*/ { } if(x != 1) /*Violation*/ { }

}

253

User Items



Examplevoid foo() {

int x = 1;

if(x >= 1) /*OK*/ { }

if(x>=1) /*Violation*/ { }

if(x >= 1) /*Violation*/ { } }

254

User Items



Examplevoid foo() {

int x = 1;

if(x <= 1) /*OK*/ { }

if(x<=1) /*Violation*/ { } if(x <= 1) /*Violation*/ { }

}

255

User Items



Examplevoid foo() {

int x = 1;

if(x > 1) /*OK*/ { }

if(x>1) /*Violation*/ { } if(x > 1) /*Violation*/ { }

}

256

User Items



Examplevoid foo() {

int x = 1;

if(x < 1) /*OK*/ { }

if(x<1) /*Violation*/ { } if(x < 1) /*Violation*/ { }

}

SpaceInSelector.ruleThere shall be no white space preceding or following a primary operatorThis rule checks whether there is no white space preceding or following a primary operator.

Reason for rule: This promotes continuity in the relationship between the operators and the members/elements on which they act. These operators are used to access members/elements and cannot be considered separately from them.

Examplestruct MyStruct { int x;};

void foo(struct MyStruct* myObj) { // ... myObj->x; /*Ok*/ myObj-> x; /*Violation*/}

257

User Items

SpaceInSelector2.ruleThere shall be no white space preceding or following a primary operatorThis rule checks whether there is no white space preceding or following a primary operator.

Reason for rule: This promotes continuity in the relationship between the operators and the members/elements on which they act. These operators are used to access members/elements and cannot be considered separately from them.

Examplechar tab1[20]; /*Ok*/char tab2 [20]; /*Violation*/

SpacesAfterComma.ruleThere shall be a single ASCII space character following all commasThis rule checks whether there is a single ASCII space character following all commas.

Reason for rule: Since commas delineate individual statements, a space shall be used to highlight this fact. This greatly improves the readability of 'C'.

Exampleint x, y; /*Ok*/int xx,yy; /*Violation*/int xxx, yyy; /*Violation*/

SpacesAfterSemicolon.ruleThere shall be a single ASCII space character following all semicolonsThis rule checks whether there is a single ASCII space character following all semicolons.

Reason for rule: Since semicolons delineate individual statements, a space shall be used to highlight this fact. This greatly improves the readability of 'C'.

Examplevoid foo() { int i;

for ( i = 0; i <= 10; i++) /*OK*/ { }

for ( i = 0;i <= 10;i++) /*Violation*/ { }}

258

User Items

SpacesAfterUnaryOperator.ruleThere should be no white space between a unary operator and its operandThis rule checks whether there is no white space between a unary operator and its operand.

Reason for rule: This promotes continuity in the relationship between the operators and their associ-ated operand. These operators act solely on their operand and cannot be considered separately from it.

Examplevoid foo(){

int i=0;--i; //OK-- i; //Violation

}

SpacesBeforeComma.ruleThere shall be a single ASCII space character following all commasThis rule checks whether there is a single ASCII space character following all commas.

Reason for rule: Since commas delineate individual statements, a space shall be used to highlight this fact. This greatly improves the readability of 'C'.

Example Onevoid foo() { int z = 73; int y=0; y=z | 0x0f; /*Ok*/ y=z|0x0f; /*Violation*/ y=z | 0x0f; /*Violation*/

Example Twovoid foo(){int i = 0;int j = 0;for(i = 0; i<5; i++,j++){} //violationfor(i = 0 ; i<5; i++, j++){} //OK

}

259

User Items

SpacesBeforeUnaryOperator.ruleThere shall be no white space between a unary operator and its operandThis rule checks whether there is no white space between a unary operator and its operand.

Reason for rule: This promotes continuity in the relationship between the operators and their associ-ated operand. These operators act solely on their operand and cannot be consider separately from it.

Examplevoid foo() { int y = 0; y++; /*Ok*/ y ++; /*Violation*/}

StatementParenthesis.ruleThere shall be no white spaces between the "return" or "sizeof" statements and its opening parenthesisThis rule checks for white spaces between the “return” and “sizeof” statements.

Reason for rule: This promotes the relationship between the statement and its argument.

Examplevoid foo() { sizeof(int); /*Ok*/ sizeof (int); /*Violation*/}

StatementParenthesis2.ruleThere shall be no white spaces between the "return" or "sizeof" statements, arguments, or expressionsThis rule checks whether there are no white spaces between the “return” and “sizeof” statements, argu-ments, or expressions.


Examplevoid foo() { sizeof(int); /*Ok*/ sizeof( int ); /*Violation*/}

260

User Items

StatementParenthesis3.ruleParentheses shall be used with the "return" and "sizeof" statementsThis rule checks whether parentheses are used with the “return” and “sizeof” statements.



int foo() { return true; /*Violation*/}

int goo() { return(true); /*Ok*/}

StructKeyword.ruleDo not use the ‘struct’ keyword to declare a variable in C++This rule checks whether your C++ code uses struct keywords to declare a variable. This rule applies only to the C++ programming language.

Reason for rule: Using the struct keyword to declare a variable improves code readability.

Example// struct keyword is unnecessary in C++ when declaring // a variable.struct Position_t {}struct Position_t Pos1; // ViolationPosition_t Pos2; // OK

261

User Items

ThrowDestructor.ruleDo not throw from within destructorThis rule checks if you throw from within a destructor. This rule is for C++ programming language only.

Reason for rule: Throwing from within a destructor may lead to memory leaks and improper object destruction. Note: This rule is enabled by default.

Exampleclass Foo{public: Foo() {} ~Foo() { // Violation throw; }};

TooManyFields.ruleAvoid structs, unions, or classes with more than 20 fieldsThis rule checks whether structs, unions, or classes have more than 20 fields. Reason for rule: Infor-mational.

Examplestruct _tA{ int i0; int i1; int i2; int i3; int i4; int i5; int i6; int i7; int i8; int i9; int i10; int i11; int i12; int i13; int i14; int i15; int i16; int i17; int i18; int i19; int i20; // more than 20 int i21;};

262

User Items

TrueDefinition.ruleIf TRUE is to be defined, & is not already defined, TRUE should be 1This rule checks whether TRUE is defined as 1.

Reason for rule: Any other use of TRUE is misleading and cannot be guaranteed to work predictably.

Example#define TRUE 0 /*Violation*/#undef TRUE#define TRUE /*Violation*/#undef TRUE#define TRUE 1 /*Ok*/

TrueTypedef.ruleIf TRUE is to be defined, & is not already defined, TRUE should be 1.This rule checks whether you defined TRUE as 1.

Reason for rule: Any other use of TRUE is misleading and cannot be guaranteed to work predictably.

Example#ifndef TRUEtypedef enum { FALSE = 0,TRUE = 3 /*Violation*/} BOOL ;#endif

TypeModifiersAfterTypes.ruleStorage type modifiers shall be associated with the type, not the variableThis rule checks whether storage type modifiers are associated with the type, not the variable.

Reason for rule: Following this convention increases readability and makes code easier to under-stand.

Exampleint static i; /*Violation*/static char j; /*Ok*/

263

User Items

TypeModifiersAfterValue.ruleStorage type modifiers shall be associated with the type, not the variableThis rule checks whether storage type modifiers are associated with the type, not with the variable.

Reason for rule: Following this convention increases readability and makes code easier to under-stand.

Examplestatic char j; /*Ok*/static i; /*Violation*/

UnionFieldNotDefined.ruleDefine fields for union declarationsThis rule checks for union declarations that do not have any defined fields.


Exampleunion UNKNOWN // hit{};

UnnecessaryCast.ruleAvoid unnecessary type castingThis rule checks if your code contains unnecessary casts. This rule applies only to the C++ program-ming language.

Reason for rule: It is not necessary to explicitly upcast to a base class. Removing unnecessary casts makes code easier to read.

Exampleclass Base { /* ... */ };class Derived : public Base { /* ... */ };void Func() { Derived *d = new Derived(); Base *b = (Base *)d; // Violation Base *b1 = d; // Okay}

264

User Items

UnnecessaryEqual.ruleRemove unnecessary “==true” in Boolean functionsThis rule checks if your code contains unnecessary “==true”s.

Reason for rule: Checking bool expression equality with true is unnecessary. Removing unneces-sary "== true"s increases legibility and efficiency.

Examplebool ret() { return true;}

bool ret2() { return ret() == true; // Violation == is unnecessary.}

UnreachableCode.ruleDo not write unreachable codeThis rule checks for unreachable code in an if statement.


Examplevoid foo (){ int i = 0;

/* ... */

if(1) /* Violation */ { i = 1; } else { i = 2; }

return;}

265

User Items

UnreachableCode2.ruleDo not write unreachable codeThis rule checks for unreachable code in an if statement.



/* ... */


return;}

UnusedLocalVariable.ruleAvoid unused local variablesThis rule checks whether any of the declared local variables were not used.

Reason for rule: Eliminating unused local variables increases efficiency and legibility.

Examplevoid func() { int i = 0; // Possible violation i is declared but not used}

266

User Items

UnusedParameter.ruleEliminate unused parametersThis rule checks for unused parameters.

Reason for rule: Eliminating unused parameters improves legibility and increases efficiency.

Exampleint Foo(int i, int k) { // Violation, k is not used. i = 5; return i;}

int Bar(int i, int j) { // Okay i += j; return i;}

UnusedPrivateMember.ruleEliminate unused private member variablesThis rule checks for unused private member variables. This rule applies only to the C++ programming language.

Reason for rule: Eliminating unused private member variables improves legibility and increases effi-ciency.

Exampleclass Foo {public: Foo(): x(0), y(0) { } int getX() { return x; }private: int x; int y; // Violation, y is declared but not used.};

267

User Items

UseParenthesesInMacros.ruleIn a function such as macros, before multiplication or division, use parenthesesThis rule checks whether parentheses are used before division or multiplication in macros.

Reason for rule: This promotes readability by highlighting the arguments of macros.

Example#define MULTI_2(x) (x*2) /*Violation*/

UsePositiveLogic.ruleUse positive logic rather than negative logic whenever practicalThis rule checks for use of negative logic. Reason for rule: The use of many logical nots "!" within an expression makes the expression difficult to understand and maintain.

Examplevoid foo( int *j) { if(j!=0){ //Violation (*j)++; } if(j==0){ } else { //OK (*j)++; }}

268

Ellemtel (Telecom Industry) Items

Rule

Access(Acces

Assign(Assign

ith a

Assign(Assign

umer-

Assign(Assign

aged

Assign(Assign

er-

Classe(Classe

m-

Classe(Classe

m-

Classe(Classe

lass

Comme(Comm

.

Comme(Comm

Comme(Comm s

Comme(Comm

is, a

Ellemtel (Telecom Industry) ItemsEllemtel (Telecom Industry) ItemsThis is a set of rules based on a C++ style guide originated by Ellemtel Telecom Systems, StockholmSweden. It is used widely in the telecommunications industry.

Notes• All Ellemtel rules are disabled by default.

• All rules are for C and C++ unless otherwise noted in the rule itself.

• The Severity Level for all Ellemtel rules is Violation unless otherwise noted in the rule text.

• In the left-hand column in the following table, the Ellemtel name is given in parentheses below the Parasoft name for the rule.

• The abbreviation “Rec” stands for Recommended.

RuleID Description

Rightss_Rights_Rule_22)

4027 Never specify public or protected member data in aclass.

ingNames1ing_Names_Rule_13)

4012 The names of variables and functions must begin wlowercase letter.

ingNames2ing_Names_Rule_14)

4013 The names of classes, structures, typedef, and enated types are to begin with an uppercase letter.

mentOperators1ment_Operators_Rule_27)

4035 A class which uses new to allocate instances manby that class must define an assignment operator.

mentOperators2ment_Operators_Rec_34)

4036 An assignment operator ought to return a const refence to the assigning object.

s1s_Rule_20_1)

4014 In class definition, public, protected and private mebers must be declared in that order.

s2s_Rule_20_2)

4015 In class definition, public, protected and private mebers must be declared in that order.

s3s_Rule_21)

4016 No member functions are to be defined within the cdefinition.

nts1ents_Rec_8)

4006 Each function should be preceeded by a comment

nts2ents_Rec_9)

4007 Use // for comments. Do not use /* and */

nts3ents_Rule_4)

4004 Every file that contains source code must be docu-mented with an introductory comment that provideinformation on the file name and its contents.

nts4ents_Rule_5)

4005 All files must include copyright information — that line starting with // Copyright

269


Compo(Comp

the after

Consta(Const

ever

Consta(Const

olic

Constr(Const

Constr(Const

Constr(Const

ed by

Constr(Const

ich tor.

DataAb(Data_A

clara-

FlowCo(Flow_

FlowCo(Flow_

FlowCo(Flow_

FlowCo(Flow_

FlowCo(Flow_

FlowCo(Flow_

FlowCo(Flow_

or

FlowCo(Flow_

rmi-

FlowCo(Flow_

ranch

FlowCo(Flow_

Formal(Forma

n the be

undStatementsound_Statements_Rec_24)

4020 Braces which enclose a block are to be placed on same column, on separate lines directly before andthe block.

nts1ants_Rule_36)

4060 Constants are to be defined using const or enum; nusing #define.

nts2ants_Rule_37)

4061 Avoid the use of numeric values in code; use symbvalues instead.

uctors&Destructors1ructors_and_Destructors_Rec_33_1)

4033 Avoid the use of global objects in constructors.

uctors&Destructors2ructors_and_Destructors_Rec_33_2)

4034 Avoid the use of global objects in destructors.

uctors&Destructors3ructors_and_Destructors_Rule_25)

4031 A class which uses new to allocate instances mnagthat class must define a copy constructor.

uctors&Destructors4ructors_and_Destructors_Rule_26)

4032 All classes which are used as base classes and whhave virtual functions must define a virtual destruc

stractionPortbstraction_Port_Rec_1)

4072 Do not directly use the pre-defined data types in detions

ntrolStatements1Control_Statements_Rec_25_1)

4021 Always use curly brackets after if construction.


4022 Always use curly brackets after else construction.


4023 Always use curly braces after for construction.


4024 Always use curly brackets after while construction.


4025 Always use curly brackets after do construction.

ntrolStructure1Control_Structures_Rec_53)

4067 Avoid the use of continue.

ntrolStructure2Control_Structures_Rec_55)

4068 Do not write logical expressions of the type if(test) if(!test) when test is a pointer.

ntrolStructure3Control_Structures_Rule_47)

4064 The code following a case label must always be tenated by a break statement.


4065 A switch statement must always contain a default bwhich handles unexpected cases.


4066 Never use goto.

Argumentsl_Arguments_Rule_32)

4054 If identifiers are given for any of the parameters, theidentifiers used in declaration and definition shouldidentical.

270


Functio(Functi

Functio(Functi

nota-

Functio(Functi

.

Functio(Functi

the

Functio(Functi

ction

Genera(Gener

Genera(Gener

Include(Includ

n-

Include(Includ

Include(Includ

irec-

Include(Includ

re-

InlineF(Inline_

InlineF(Inline_

InlineF(Inline_

btain

Membe(Memb

const

Memor(Memo

Memor(Memo

Memor(Memo

en

Miscell(Miscel

nArguments1on_Arguments_Rec_41)

4053 Avoid functions with many arguments.

nArguments2on_Arguments_Rule_31)

4052 Do not use unspecified function arguments (ellipsistion).

ns1ons_Rec_20)

4017 Always provide the return type of function explicitly

ns2ons_Rec_22)

4018 In function definition, the return type of the functionshould be written on a separate line directly abovefunction name.

ns3ons_Rec_23)

4019 Always write the left parenthesis directly after a funname.

l1al_Rec_47_1)

4058 Long functions have disadvantages

l2al_Rec_47_2)

4059 Avoid long and complex functions.

Files1e_Files_Rec_12)

4010 Every implementation file should declare a local costant string that describes the file.

Files2e_Files_Rec_13)

4011 Never include other files in an .icc file.

Files3e_Files_Rule_10)

4009 Never specify relative Unix file names in #include dtives.

Files4e_Files_Rule_7)

4008 Every include file must contain a mechanism that pvents multiple inclusion of the file.

unctions1Functions_Rec_31_1)

4029 Constructors must not be inline

unctions2Functions_Rec_31_2)

4030 Destructors must not be inline

unctions3Functions_Rule_35)

4057 Do not use the preprocessor directive #define to omore efficient code; instead use inline functions.

rFunctionsReturnTypeser_Function_Return_Types_Rule_29)

4051 A public member function must never return a non-reference or pointer to member data.

yAllocation1ry_Allocation_Rec_57)

4071 Avoid global data if at all possible.

yAllocation2ry_Allocation_Rule_50)

4069 Do not use malloc, realloc, or free.

yAllocation3ry_Allocation_Rule_51)

4070 Always provide empty brackets ("[ ]") for delete whdeallocating arrays.

aneouslaneous_Rec_27)

4026 Do not use spaces around '.' or '->'.

271


Naming(Namin

of the

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Operat(Opera

Pointer(Pointe

pera-

Pointer(Pointe

Pointer(Pointe

pera-es in

Pointer(Pointe

ossi-

FilesgFiles_Rec_7)

4004 An include file for a class should have a file name form <class name> + extension.

orOverloading1tor_Overloading_Rec_36_1)

4037 Do not overload operator+=


4038 Do not overload operator-=


4039 Overload operator != if you overload operator ==.


4040 Overload operator == if you overload operator !=.


4041 Overload operator || if you overload operator &&.


4042 Overload operator && if you overload operator ||.


4043 Overload operator > if you overload operator <.


4044 Overload operator < if you overload operator >.


4045 Overload operator >= if you overload operator <=.


4046 Overload operator <= if you overload operator >=.


4047 Overload operator -- if you overload operator ++.


4048 Overload operator ++ if you overload operator --.


4049 Overload operator - if you overload operator +.


4050 Overload operator + if you overload operator -.

ArithmeticPort1r_Arithmetic_Port_Rec_17)

4085 Avoid using shift operations instead of arithmetic otions.

ArithmeticPort2r_Arithmetic_Port_Rec_18)

4086 Avoid pointer arithmetic

s&References1rs_and_References_Rec_26)

4087 The dereference operator * and the "address-of" otor & should be directly connected to the type namdeclaration and definition.

s&References2rs_and_References_Rec_48)

4063 Pointers to pointers should be avoided whenever pble.

272


Return(Return

Return(Return

to a

SizeOfT(Size_o

SizeOfT(Size_o

SizeOfT(Size_o

SizeOfT(Size_o

SizeOfT(Size_o

SizeOfT(Size_o

SizeOfT(Size_o

SizeOfT(Size_o

Structu(Struct

lass

Structu(Struct

Structu(Struct

e file

Structu(Struct

".icc"

TypeCo(Type_

ter

TypeCo(Type_

orter

TypeCo(Type_

TypeCo(Type_

Variabl(Variab

ration

Types&Values1_Types_and_Values_Rule_33)

4055 Every function shall have an explicit return type.

Types&Values2_Types_and_Values_Rule_34)

4056 A function must never return a pointer or referencelocal variable.

ypesPort1f_Types_Port_Rec_2_1)

4073 Attempt to cast long pointer to int pointer.


4074 Attempt to assign long value to int.


4075 Function cast long to int


4076 Constant is an unsigned int


4077 Constant is an unsigned int


4078 Assign an int literal to long.


4079 Attempt to cast an int pointer as a long pointer.


4080 32-bit multiplication

reOfCode1ure_of_Code_Rec_3)

4002 An include file should not contain more than one cdefinition.

reOfCode2ure_of_Code_Rule_1)

4000 User include files should have the extension ".hh"


4001 Implementation files in C++ should always have thname extension ".cc".


4003 Inline definition files always have the file extension

nversionsPort1Conversions_Port_Rec_6_1)

4081 Be careful not to make type conversions from shortype to longer type.


4082 Be careful not to make type conversions from a shtype to a longer one.


4083 Attempt to cast long value to double.

nversionsPort4Conversions_Port_Rec_7)

4084 Do not cast a pointer as an int.

esles_Rule_39)

4062 Each variable is to be declared in a separate declastatement.

273


AccessRights.ruleNever specify public or protected member data in a class.The use of public variables is discouraged because a public variable represents a violation of one of the basic principles of object-oriented programming, namely, encapsulation of data.

For example, if there is a class of the type BankAccount, in which account_balance is a public variable, the value of this variable may be changed by any user of the class.

However, if the variable has been declared private, its value may be changed only by the member func-tions of the class. An arbitrary function in a program can change public data which may lead to errors that are difficult to locate. If public data is avoided, its internal representation may be changed without users of the class having to modify their code.

A principle of class design is to maintain the stability of the public interface of the class. The implemen-tation of a class should not be a concern for its users. The use of protected variables in a class are not recommended, since its variables become visible to its derived classes.

The names of types or variables in a base class may then not be changed since the derived classes may depend on them. If a derived class, for some reason, must access data in its base class, one solu-tion may be to make a special protected interface in the base class, containing functions which return private data. This solution would not imply any degradation of performance if the functions are defined inline.

Reason for rule: A public variable represents a violation of one of the basic principles of object-ori-ented programming, namely, encapsulation of data.

274


Exampleclass Test1{public: int i; // Violation};

class Test2{protected: int i; // Violation};

class Test3{private: int i; // Ok };

class Test4{public: int getI(); // Ok};

class Test5{protected: int getI(); // Ok};

class Test6{private: int getI(); // Ok};

OutputUse only private member variable.

ReferenceOrigin: Ellemtel Coding Standards

http://www.cs.umd.edu/users/cml/cstyle/Ellemtel-rules-mm.html

From: 7 Classes - 7.1 Considerations regarding Access Rights - Rule 22

275


AssigningNames1.ruleThe names of variables and functions must begin with a lowercase letter.

Examplevoid Foo(); // violationvoid foo2(); // ok

void test() {

int I; // violation int j; // ok

}

OutputThe names of variables and functions must begin with a lowercase letter.



From: 5 Assigning Names - Rule 13

AssigningNames2.ruleThe names of classes, structures, typedef, and enumerated types are to begin with an uppercase letter.

Example

class Test1{}; // OK class badClass{}; // Violation

OutputThe names of classes, structures, typedef, and enumerated types are to begin with an uppercase letter.


http:www.cs.umd.edu/users/cml/cstyle/Ellemtel-rules-mm.html

From: 5 Assigning Names - Rule 14

276


AssignmentOperators1.ruleA class which uses new to allocate instances managed by that class must define an assignment operator.

Example// Violationclass Test1{public: Test1();private: int *p;

};

Test1::Test1() { p = new int;}

// Ok

class Test2{public: Test2(); Test2(Test2&);private: int *p;

};

Test2::Test2() { p = new int;

}

OutputA class which uses new must define an assignment operator.



From: 7 Classes - 7.6 Asignments Operators - Rule 27

277


AssignmentOperators2.ruleAn assignment operator ought to return a const reference to the assigning object.

Example

// Okclass TestOk {public: const TestOk& operator=(const TestOk&);

};

// Violationclass Test1 {public: void operator=(const Test1&);

};

// Violationclass Test2 {public: Test2& operator=(const Test2&);

};

OutputAn assignment operator ought to return a const reference to the assigning object.



From: 7 Classes - 7.6 Assignment Operators - Rec. 34

278


Classes1.ruleIn class definition, public, protected and private members must be declared in that order.

Exampleclass Test1 { // Violation

protected: void foo2();

private: void foo3();

public: void foo4();

};

OutputPublic section must be before protected and private sections.



From: 6 Style - 6.1 Classes - Rule 20

279


Classes2.ruleIn class definition, public, protected and private members must be declared in that order.

Exampleclass Test1 { // Violation

public: void foo4();

private: void foo3();

protected: void foo2();

};

OutputProtected section must be before private section.




280


Classes3.ruleNo member functions are to be defined within the class definition.

Exampleclass TestClass1{public: void foo() {}; // Violation void foo2(); // Ok };

void TestClass1::foo2() { // Ok}

OutputNo member functions are to be defined within the class definition.




281


Comments1.ruleEach function should be preceeded by a comment.

Example

// comment with description for foo() function.void foo(); //Ok

void foo2(); //Violation

// comment with description for foo() function.void foo() //Ok{}

void foo2() //Violation{}

OutputThere is no comment before function.



From: 4 Source Code in Files - 4.3 Comments - Rec. 8

Comments2.ruleUse // for comments. Do not use /* and */Reason for rule: If the characters // are consistently used for writing comments, then the combination/* */ may be used to make comments out of entire sections of code during the development and debug-ging phases. C++, however, does not allow comments to be nested using /* */.

Example

// good comment/* do not use this comment style */

OutputUse // comments only.



From: 4 Source Code in Files - 4.3 Comments - Rec. 9

282


Comments3.ruleEvery file that contains source code must be documented with an introductory comment that provides information on the file name and its contents.

Example

// File: <short description of the file>

OutputDocument filename with some introductory comment.



From: 4 Source Code in Files - 4.3 Comments - Rule 4

Comments4.ruleAll files must include copyright information — that is, a line starting with // Copyright

OutputAdd copyright information to filename.



From: 4 Source Code in Files - 4.3 Comments - Rule 5

283


CompoundStatements.ruleBraces which enclose a block are to be placed on the same column, on separate lines directly before and after the block.

Example

// Badvoid foo1(){}

// Okvoid foo2(){}

// Badvoid foo3(){}

// Badvoid foo4() {

int i; // Bad if (i>0) { } else { }}

class Test { // Bad};

// Goodvoid foo5() {

int i; if (i>0) { // ... } else {

// ... } }

284


// badclass Test2 { private:

};

// Okclass Test3 { // ...

};

// okclass Test4 { // ...

}; // ...

// bad class Test5 { // ...

int k;}; // ...

OutputOutput 1Opening { and closing } should be on the same column.

Output 2Opening { should be alone on the line.

Output 3Closing } should be alone on the line.



From: 6 Style Classes - 6.3 Compound Statements- Rec. 24

285


Constants1.ruleConstants are to be defined using const or enum; never using #define.Reason for rule: The preprocessor performs a textual substitution for macros in the source code which is then compiled. This has a number of negative consequences.

For example, if a constant has been defined using #define, the name of the constant is not recog-nized in many debuggers. If the constant is represented by an expression, this expression may be evaluated differently for different instantiations, depending on the scope of the name. In addition, mac-ros are, at times, incorrectly written.

Example// Violation#define PI 3.1416

OutputConstats are to be defined using const or enum; never using #define.



From: 10 Constants - Rule 36

Constants2.ruleAvoid the use of numeric values in code; use symbolic values instead.

Example#define buff 256#define OK 1



if ( tabColors[0] == 1 ) /*Violation*/ { /*...*/

286


}


OutputHard coded value: $name



From: 10 Constants - Rule 37

287


Constructors&Destructors1.ruleAvoid the use of global objects in constructors.

Exampleint globalvar=0;bool alreadyUsed=false;

class Test{ public: Test(); ~Test();};

Test::Test() { // Violation globalvar++; alreadyUsed=true;}

Test::~Test() { // Violation globalvar--; alreadyUsed=false;}

OutputAvoid the use of global objects in constructors: LIST(A).



From: 7 Classes - 7.5 Constructors and Destructors - Rec. 33

288


Constructors&Destructors2.ruleAvoid the use of global objects in destructors.

Exampleint globalvar=0;bool alreadyUsed=false;

class Test{ public: Test(); ~Test();};

Test::Test() { // Violation globalvar++; alreadyUsed=true;}

Test::~Test() { // Violation globalvar--; alreadyUsed=false;}

OutputAvoid the use of global objects in destructors: LIST(A).



From: 7 Classes - 7.5 Constructors and Destructors - Rec. 33

289


Constructors&Destructors3.ruleA class which uses new to allocate instances mnaged by that class must define a copy constructor.

Example

// Violationclass Test1{public: Test1();private: int *p;

};


}

// Okclass Test2{public: Test2(); Test2(Test2&);private: int *p;

};


}

OutputA class which uses new must define a copy constructor: $name.



From: 7 Classes - 7.5 Constructors and destructors - Rule 25

290


Constructors&Destructors4.ruleAll classes which are used as base classes and which have virtual functions must define a virtual destructor.Reason for rule: If a class, having virtual functions but without virtual destructors, is used as a base class, there may be a surprise if pointers to the class are used. If such a pointer is assigned to an instance of a derived class and if delete is then used on this pointer, only the base class' destructor will be invoked. If the program depends on the derived class' destructor being invoked, the program will fail.

Example// violation in this example// one should add ~Base in Base class

class Base{ public: virtual void foo();};

class Derived : public Base {};

OutputAll classes which are used as base classes and which have virtual functions must define a virtual destructor.



From: 7 Classes - 7.5 Constructors and Destructors - Rule 26

291


DataAbstractionPort.ruleDo not directly use the pre-defined data types in declarationsReason for rule: An excellent way of transforming your world to a "vale of tears" is to directly use thepre-defined data types in declarations.

If it is later necessary, due to portability problems, to change the return type of a function, it may be necessary to make change at a large number of places in the code.

One way to avoid this is to declare a new type name using classes or typedefs to represent the types of variables used. In this way, changes can be more easily made.

This may be used to give data a physical unit, such as kilogram or meter. Such code is more easily reviewed.

For example, when the code is functioning poorly, it may be noticed that a variable representing meters has been assigned to a variable representing kilograms.

It should be noted that a typedef does not create a new type, only an alternative name for a type. This means that if you have declared typedef int Error, a variable of the type Error may be used anywhere where an int may be used.

Exampletypedef int MyInt ;

int main() { int a; // Violation short int b; // Violation float c; // Violation char d; // Violation unsigned int a2; // Violation

MyInt a1; // Ok }

void foo(signed int bb) {} // violation - parameter type

int bar() { // violation - function return type return 0;

}

OutputAvoid the direct use of pre-defined data types in declaration: $name



From: 18 Portable Code - 18.1 Data Abstraction - Port. Rec. 1

292


FlowControlStatements1.ruleAlways use curly brackets after if construction.

Examplevoid foo2();

void foo(int x) {

if (x>0) {} // Ok // violation if (x>0) foo2();

// violation if (x>0) foo2(); else if (x < -1) { // ok } }

OutputAlways use curly brackets after if construction.



From: 6 style - 6.4 Flow Control Statements - Rec. 25

293


FlowControlStatements2.ruleAlways use curly brackets after else construction.

Examplevoid foo2();

void foo(int x) {

if (x>0) foo2(); else if (x < -1) { // ok } // violation if (x >0) { } else foo2();}

OutputAlways use curly brace after else construction.




294


FlowControlStatements3.ruleAlways use curly braces after for construction.

Examplevoid foo2();

void foo(int x) {

// violation for (int i=0; i< 10; i++) foo2();

// ok for (int j=0; j< 10; j++) {}

}

OutputAlways use curly braces after for construction.




295


FlowControlStatements4.ruleAlways use curly brackets after while construction.

Examplevoid foo2();

void foo(int x) {

// ok while (x > 10) { }

// violation while (1) foo2();

}

OutputAlways use curly braces after while construction.




296


FlowControlStatements5.ruleAlways use curly brackets after do construction.

Examplevoid foo2();

void foo(int x) { // violation do foo2(); while(1);

// Ok do { } while (1);

}

OutputAlways use curly brackets after do construction.




297


FlowControlStructure1.ruleAvoid the use of continue.Reason for rule: continue can be used to exit from loops. However, code may be more comprehensi-ble by using an else clause instead.

Examplevoid foo() {

for(int i=0;i<100;i++) { continue; // Violation here }

}

OutputAvoid the use of continue.



From: 14 Flow Control Structures - Rec. 53

298


FlowControlStructure2.ruleDo not write logical expressions of the type if(test) or if(!test) when test is a pointer.Reason for rule: We do not recommend logical tests such as if(pointer) if pointer is a variable of pointer-type. The only reason is readablity; many programmers find it difficult to read such code.

Examplevoid foo() {

int* ptr;

if (ptr) { // Violation }

if (!ptr) { // Violation } if (ptr==0) { // Ok } }

OutputDo not write logical expressions of the type if(test) or if(!test) when test is a pointer.



From: 14 Flow Control Structures - Rec. 55

299


FlowControlStructure3.ruleThe code following a case label must always be terminated by a break statement. Reason for rule: If the code which follows a case label is not terminated by break, the execution con-tinues after the next case label. This means that poorly tested code can be erroneous and still seem to work.

Examplevoid foo() {

int tag;

switch ( tag ) { // violation here case 0: { // Do something // Next statement is a call to foo() inside next case }

case 1: { foo(); // Do something else break; // Now we leave the switch-statement }

}

}

OutputThe code following a case label must always be terminated by a break state-ment.



From: 14 Flow Control Structures - Rule 47

300


FlowControlStructure4.ruleA switch statement must always contain a default branch which handles unexpected cases.

Example

void foo() {

int tag;

// violation here switch ( tag ) { case 0: { // Do something // Next statement is a call to foo() inside next case }

case 1: { foo(); // Do something else break; // Now we leave the switch-statement }

}

}

OutputA switch statement must always contain a default branch which handles unex-pected cases.




301


FlowControlStructure5.ruleNever use goto.

Example

void foo() {

int j; for(int i=0;i<10;i++) { goto alabel; // Violation - Never use goto }

alabel: j=0;

}

OutputNever use goto.




FormalArguments.ruleIf identifiers are given for any of the parameters, then the identifiers used in declaration and definition should be identical.

Examplevoid foo1(); // Okvoid foo2(int a, int b); // Okvoid foo2(int a, int b) {} void foo4(int , int ); // Okvoid foo4(int x, int y ) {}void foo5(int a, int b); // Violationvoid foo5(int x, int y ) {}

OutputIdentifiers given in declaration and definition of $function should be iden-tical.



From: 9 Function - 9.3 Formal Arguments - Rule 32

302


FunctionArguments1.ruleAvoid functions with many arguments.Reason for rule: Functions having long lists of arguments look complicated, are difficult to read, and can indicate poor design. In addition, they are difficult to use and to maintain.

Examplevoid foo(int a,int b,int c,int d,int e,int f); //Violation

OutputAvoid functions with many arguments.



From: 9 Function - 9.1 Function Arguments - Rec. 41

FunctionArguments2.ruleDo not use unspecified function arguments (ellipsis notation).Reason for rule: The best known function which uses unspecified arguments is printf(). The use of such functions is not advised since the strong type checking provided by C++ is thereby avoided. Some of the possibilities provided by unspecified function arguments can be attained by overloading functions and by using default arguments.

Examplevoid foo(int, ...) { // Violation

}

OutputDo not use unspecified function arguments (ellipsis notation).



From: 9 Functions - 9.1 Function Arguments - Rule 31

303


Functions1.ruleAlways provide the return type of function explicitly.

Examplefoo() { //violation}

int foo2() { //ok}

OutputAlways provide the return type of function explicitly.



From: 6 Style - 6.2 Functions - Rec. 20

Functions2.ruleIn function definition, the return type of the function should be written on a separate line directly above the function name.

Examplesint foo() { //Violation return 0; }

int foo2() { //Ok return 0; }

OutputIn function definition, the return type of the function should be written on a separate line directly above the function name.




304


Functions3.ruleAlways write the left parenthesis directly after a function name.

Examplevoidfoo2() { //Ok}

void foo () { //Violation}

OutputAlways write the left parenthesis directly after a function name.




General1.ruleLong functions have disadvantagesReason for rule: If a function is too long, it can be difficult to comprehend. Generally, it can be said that a function should not be longer than two pages, since that is about how much that can be compre-hended at one time.

If an error situation is discovered at the end of an extremely long function, it may be difficult for the function to clean up after itself and to "undo" as much as possible before reporting the error to the call-ing function.

By always using short functions, such an error can be more exactly localized.

Examplevoid too_long_function() { int a1; int a2; int a3; int a4; int a5; int a6; int a7; int a8; int a9; int a10; int a11; int a12; int a13; int a14;

305


int a15; int a16; int a17; int a18; int a19; int a20; int a21; int a22; int a23; int a24; int a25; int a26; int a27; int a28; int a29; int a30; int a31; int a32; int a33; int a34; int a35; int a36; int a37; int a38; int a39; int a40; int a41; int a42; int a43; int a44; int a45; int a46; int a47; int a48; int a49; int a50; int a51; int a52; int a53; int a54;

}

OutputFunction is too large.



From: 9 Functions - 9.7 General - Rec 47

306


General2.ruleAvoid long and complex functions.Reason for rule: Complex functions are difficult to test. If a function consists of 15 nested if state-ments, then there are 2**15 (or 32768) different branches to test in a single function.

Example

void func(int i) { if (1) { // do something; } else { // do another; } do { } while(1); switch(i) { case 1: break; default: break; }

if (1) { // do something; } else { // do another; }



}

OutputNumber of block in a function: $count



From: 9 Functions - 9.7 General - Rec. 47

307


IncludeFiles1.ruleEvery implementation file should declare a local constant string that describes the file.Reason for rule: This allows the UNIX command 'what' to be used to obtain information on the file revision.

Example

// Okstatic const char* sccsid = "@(#) Exception.cc ; rev. A, Copyright ... ";

OutputEvery implementation file should declare a local constant string.



From: 4 Source Code in Files - 4.4 include Files - Rec 12

IncludeFiles2.ruleNever include other files in an .icc file.

Example

// some.icc: #include <stdio.h>

OutputNever include other files in an .icc file.



From: 4 Source Code in Files - 4.4 Include Files - Rec. 13

308


IncludeFiles3.ruleNever specify relative Unix file names in #include directives.

Example#include "foo.hh"

// violation#include "./foo.hh"

OutputNever specify relative UNIX names in #include directives: $name



From: 4 Source Code in Files - 4.4 Include Files - Rule 10

IncludeFiles4.ruleEvery include file must contain a mechanism that prevents multiple inclusion of the file.

Example// OKfile foo.hh:#ifndef FOO_HH#define FOO_HH

int i;#endif

Output1$defname should appear in first #ifndef preprocessor directive.

Output2$defname should appear in first #define preprocessor directive.



From: 4 Source Code in Files - 4.4 Include Files - Rule 7

309


InlineFunctions1.ruleConstructors must not be inlineReason for rule: Functions which invoke other inline functions often become too complex for the com-piler to be able to make them inline despite their apparent smallness.

This problem is especially common with constructors and destructors. A constructor always invokes the constructors of its base classes and member data before executing its own code. Always avoid inline constructors and destructors!

Example

class Test1{ public: Test1(){} // Violation};

class Test2{ public: Test2(); // Ok};

Test2::Test2() { // Ok}

class Test3{ public: Test3();};

inline Test3::Test3() { // Violation}

OutputConstructors must not be inline.



From: 7 Classes - 7.2 Inline Functions - Rec. 31

310


InlineFunctions2.ruleDestructors must not be inlineReason for rule: Functions which invoke other inline functions often become too complex for the com-piler to be able to make them inline despite their apparent smallness.

This problem is especially common with constructors and destructors. A constructor always invokes the constructors of its base classes and member data before executing its own code. Always avoid inline constructors and destructors!

Exampleclass Test1{ public: ~Test1(){} // Violation};

class Test2{ public: ~Test2();};

Test2::~Test2() { // Ok}

class Test3{ public: ~Test3();};

inline Test3::~Test3() { // Violation}

OutputDestructors must not be inline.



From: 7 Classes - 7.2 Inline Functions - Rec. 31

311


InlineFunctions3.ruleDo not use the preprocessor directive #define to obtain more efficient code; instead use inline functions.

Example

// Violation#define SUM(A,B) ((A)+(B))

OutputDo not use the preprocessor directive #define to obtain more efficient code; instead use inline functions.



From: 9 Functions - 9.5 Inline Functions - Rule 35

MemberFunctionsReturnTypes.ruleA public member function must never return a non-const reference or pointer to member data.Reason for rule: By allowing a user direct access to the private member data of an object, this data may be changed in ways not intended by the class designer. This may lead to reduced confidence in the designer's code: a situation to be avoided.

Exampleclass Test {public: int* GetI1(); // Violation int& GetI2(); // Violation const int* GetI3() ; const int& GetI4() ; private: int _i;};

int* Test::GetI1() { return &_i;}

int& Test::GetI2() { return _i;}

312


const int* Test::GetI3() { return &_i;}

const int& Test::GetI4() { return _i;}

OutputA public member function must never return a non-const reference or pointer to member data: LIST(A)



From: 7 Classes - 7.8 Member Function Return Types - Rule 29

MemoryAllocation1.ruleAvoid global data if at all possible.

Exampleint someGlobalVariable;

OutputAvoid global data if at all possible.



From: 16 Memory allocation - Rec. 57

313


MemoryAllocation2.ruleDo not use malloc, realloc, or free.Reason for rule: In C, malloc, realloc, and free are used to allocate memory dynamically on the heap. This may lead to conflicts with the use of the new and delete operators in C++. It is dangerous to invoke delete for a pointer obtained via malloc/realloc, invoke malloc/realloc for objects having con-structors, and invoke free for anything allocated using new. Because of these dangers, avoid the use of malloc, realloc, and free whenever possible.

Example#include <stdlib.h> #include <stdio.h>#include <malloc.h>

void foo() {

char *string; char* string2;

string = (char *)malloc(10); // violation string2 = (char*)realloc(string,12); // violation

free(string); // violation free(string2); // violation

}

OutputDo not use malloc, realloc or free.



From: 16 Memory Allocation - Rule 50

314


MemoryAllocation3.ruleAlways provide empty brackets ("[ ]") for delete when deallocating arrays.

Examplevoid foo(char **p) { delete [] p; //OK delete p[0]; //Violation

}

OutputAlways provide empty brackets ("[]") for delete when deallocating arrays.



From: 16 Memory Allocation - Rule 51

315


Miscellaneous.ruleDo not use spaces around '.' or '->'.

Exampleclass Test {public: Test(); void test();};

void foo() { Test t=Test();

t.test(); // ok t. test(); // violation t .test(); // violation

Test* t2 = new Test(); t2->test(); // ok t2 ->test(); // violation t2-> test(); // violation}

OutputDo not use spaces around '.' or '->'.




316


NamingFiles.ruleAn include file for a class should have a file name of the form <class name> + extension. Reason for Rule: Use uppercase and lowercase letters in the same way as in the source code. Sinceclass names must generally be unique within a large context, it is appropriate to utilize this characteris-tic when naming its include file. This convention makes it easy to locate a class definition using afile-based tool.

Example

//OKMyClass2.hh:class MyClass2 { };

//ViolationMyClass.hh:class MyClass2 { };

OutputHeader file has name: $headerName.h but should have a name: $className.h



From: 4 Source Code in Files - 4.2 Naming Files - Rec. 7

317


OperatorOverloading1.ruleDo not overload operator+=

Exampleclass A { //Violation public: A& operator + (A& a);};

class B { //Ok public: B& operator + (B& b); B& operator += (B& b);};

OutputNo overload operator+=



From: 7 Classes - 7.7 Operator Overloading - Rec. 36

OperatorOverloading2.ruleDo not overload operator-=

Exampleclass C { //Violation public: C& operator - (C& c);};

class D { //Ok public: D& operator - (D& d); D& operator -= (D& d);};

OutputNo overload operator-=




318


OperatorOverloading3.ruleOverload operator != if you overload operator ==.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.

Note: This rule is for C++ only. The Severity Level for this rule is Possible Violation.

Exampleclass C { //Violation public: bool operator == (C& c);};

class D { //Ok public: bool operator == (D& d); bool operator != (D& d);};

OutputOverload operator != if you overload operator ==.




319


OperatorOverloading4.ruleOverload operator == if you overload operator !=.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Exampleclass C { //Violation public: bool operator != (C& c);};

class D { //Ok public: bool operator == (D& d); bool operator != (D& d);};

OutputOverload operator == if you overload operator !=.




320


OperatorOverloading5.ruleOverload operator || if you overload operator &&.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Exampleclass C { //Violation public: bool operator && (C& c);};

class D { //Ok public: bool operator && (D& d); bool operator || (D& d);};

OutputOverload operator || if you overload operator &&.




321


OperatorOverloading6.ruleOverload operator && if you overload operator ||.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Exampleclass C { //Violation public: bool operator || (C& c);};

class D { //Ok public: bool operator && (D& d); bool operator || (D& d);};

OutputOverload operator && if you overload operator ||.




322


OperatorOverloading7.ruleOverload operator > if you overload operator <.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Exampleclass C { //Violation public: bool operator < (C& c);};

class D { //Ok public: bool operator < (D& d); bool operator > (D& d);};

OutputOverload operator > if you overload operator <.




323


OperatorOverloading8.ruleOverload operator < if you overload operator >.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Exampleclass C { //Violation public: bool operator > (C& c);};

class D { //Ok public: bool operator < (D& d); bool operator > (D& d);};

OutputOverload operator < if you overload operator >.




324


OperatorOverloading9.ruleOverload operator >= if you overload operator <=.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Exampleclass C { //Violation public: bool operator <= (C& c);};

class D { //Ok public: bool operator <= (D& d); bool operator >= (D& d);};

OutputOverload operator >= if you overload operator <=.




325


OperatorOverloading10.ruleOverload operator <= if you overload operator >=.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Examplesclass C { //Violation public: bool operator >= (C& c);};

class D { //Ok public: bool operator <= (D& d); bool operator >= (D& d);};

OutputOverload operator <= if you overload operator >=.




326


OperatorOverloading11.ruleOverload operator -- if you overload operator ++.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Examplesclass A { //Violation public: A& operator ++ ();};

class B { //Ok public: B& operator ++ (); B& operator -- ();};

OutputOverload operator -- if you overload operator ++.




327


OperatorOverloading12.ruleOverload operator ++ if you overload operator --.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Exampleclass A { //Violation public: A& operator -- ();};

class B { //Ok public: B& operator ++ (); B& operator -- ();};

OutputOverload operator ++ if you overload operator --.




328


OperatorOverloading13.ruleOverload operator - if you overload operator +.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Exampleclass A { //Violation public: A& operator + (A& a);};

class B { //Ok public: B& operator + (B& b); B& operator - (B& b);};

OutputOverload operator - if you overload operator +.




329


OperatorOverloading14.ruleOverload operator + if you overload operator -.Reason for rule: When a client of a class is allowed to apply an operator against a class, it also expects to be able to apply the negation of that operator against a class. A good example is the opera-tor==; its semantic opposite is the operator!=, which should also be defined if operator== was defined.


Exampleclass A { //Violation public: A& operator - (A& a);};

class B { //Ok public: B& operator + (B& b); B& operator - (B& b);};

OutputOverload operator + if you overload operator -.




PointerArithmeticPort1.ruleAvoid using shift operations instead of arithmetic operations.

Examplevoid foo() { int c =8 << 2; // Violation}

OutputAvoid using shift operations instead of arithmetic operations.



From: 18 Portable Code - 18.8 Pointer Arithmetic - Port. Rec. 17

330


PointerArithmeticPort2.ruleAvoid pointer arithmeticReason for rule: Pointer arithmetic can be portable. The operators == and != are defined for all point-ers of the same type, while the use of the operators <, >, <=, >= are portable only if they are usedbetween pointers which point into the same array.

Exampleint* returnptr();

void foo() {

int* a; int* b;

if (a==b) {} // Violation

if (returnptr()>=b) {} // Violation if (b<returnptr()) {} // Violation

}

OutputAvoid pointer arithmetic.



From: 18 Portable Code - 18.8 Pointer Arithmetic - Port. Rec. 18

331


Pointers&References1.ruleThe dereference operator * and the "address-of" operator & should be directly connected to the type names in declaration and definition.

Examplevoid foo() { int k=42; int *p1; // violation int* p2; // ok

int &r1 = k; // violation int& r2 = k; // Ok}

Output* and & should be connected to type name and not variable: $name



From: 6 Style - 6.5 Pointers and references - Rec. 26

332


Pointers&References2.rulePointers to pointers should be avoided whenever possible.Reason for rule: Pointers to pointers normally ought not be used. Instead, a class should be declared, which has a member variable of the pointer type. This improves the readability of the code and encour-ages data abstraction. By improving the readability of code, the probability of failure is reduced.

One exception to this rule is represented by functions which provide interfaces to other languages (such as C). These are likely to only allow pre-defined data types to be used as arguments in the inter-face, in which case pointers to pointers are needed. Another example is the second argument to the main function, which must have the type char*[].

Examplevoid foo() {

int** a; // Violation

}

OutputPointers to pointers should be avoided whenever possible.



From: 12 Pointers and References - Rec. 48

ReturnTypes&Values1.ruleEvery function shall have an explicit return type.

Exampleint goo(void); /*Ok*/foo(void); /*Violation*/

OutputEvery function shall have an explicit return type.



From: 9 Function - 9.4 return Type ans Values - Rule 33

333


ReturnTypes&Values2.ruleA function must never return a pointer or reference to a local variable.Reason for rule: If a function returns a reference or a pointer to a local variable, the memory to which it refers will already have been deallocated, when this reference or pointer is used. The compiler may or may not give a warning for this.

Exampleint* foo() { // violation int i; return &i; }

int& bar() { // violation int i; return i; }

int bar2() { int i=0; return i; }

OutputA function must never return a pointer or reference to a local variable.



From: 9 Functions - 94. Return Types and Values - Rule 34

334


SizeOfTypesPort1.ruleAttempt to cast long pointer to int pointer.Reason for rule: Do not assume that int and long have the same size. A pointer to a long should not be cast to an int pointer.

Note: The Severity Level for this rule is Possible Severe Violation.

Examplevoid foo() { int *intPointer; long *longPointer; intPointer = (int *)longPointer; // Violation}

OutputAttempt to cast long pointer to int pointer.



From: 18 Portable Code - 18.2 Size of Types - Port. Rec. 2

SizeOfTypesPort2.ruleAttempt to assign long value to int.Reason for rule: Do not assume that int and long have the same size. Assigning a long int to an int may result in truncation when porting from 32 bit to 64 bit applications.

Examplevoid foo(){ int iVal = 72; long lVal = 6; iVal = lVal; //Violation iVal = (int)lVal; //Violation too}

OutputAttempt to assign long value to int.




335


SizeOfTypesPort3.ruleFunction cast long to intReason for rule: Do not assume that int and long have the same size. Assigning a long int to an int may result in truncation when porting from 32 bit to 64 bit applications.

Examplevoid foo(int iVal){ long lVal ; //.. set big value for lVal foo(lVal); //Violation foo((int)lVal); //Violation too}

Outputfunction cast long to int




SizeOfTypesPort4.ruleConstant is an unsigned intReason for rule: Do not assume that int and long have the same size. Constant assignment to long should not involve int literals.

Examplevoid foo(){ long longValue; longValue &= ~(0x00000000008000000000);

// Violation: leading zeros not significant.}

OutputConstant is an unsigned int




336


SizeOfTypesPort5.ruleConstant is an unsigned intReason for rule: Do not assume that int and long have the same size. Constant assignment to long should not involve int literals.

Example

void foo() {long longValue;longValue = 0x00000000008000000000;

// Violation: leading zeros not significant.}

OutputConstant is an unsigned int.




SizeOfTypesPort6.ruleAssign an int literal to long.Reason for rule: Do not assume that int and long have the same size. An int literal is 32 bits in length. Assignment of int literal to long data value could lead to garbage in the upper 32 bits, or truncation if the int literal takes up more than 32 bits.

Examplevoid foo(){ long lVal = 1; //Violation}

OutputAssign an int literal to long.




337


SizeOfTypesPort7.ruleAttempt to cast an int pointer as a long pointer.Reason for rule: Do not assume that int and long have the same size. Do not cast an int pointer to a long pointer. These are not compatible in 64 bit, even though in 32 bit they would have been inter-changeable.

Note: The Severity Level for this rule is Possible Severe Violation.

Examplevoid f2005() { int *intPointer; long *longPointer; longPointer = (long *)intPointer; // Violation}

OutputAttempt to cast an int pointer as a long pointer.




SizeOfTypesPort8.rule32-bit multiplicationReason for rule: Do not assume that int and long have the same size. 32-bit multiplication assigned to long value may result in truncation.

Example

void foo() { long longValue; longValue = 2000000 * 3000000; // Violation - 32 bit multiplication longValue = 2000000L * 3000000; // Ok - 64 bit multiplication}

Output32-bit multiplication.




338


StructureOfCode1.ruleAn include file should not contain more than one class definition.

ExampleIn header file:// violationclass testClass1{};class testClass2{};

OutputAn include file should not contain more than one class definition.



From: 4 Source Code in Files - 4.1 Structure of Code - Rec. 3

StructureOfCode2.ruleUser include files should have the extension ".hh"

Example

#include "MyClass.h" //Violation#include "MyClass2.hh" //Ok

OutputUser include files should have the extension ".hh"



From: 4 Source Code in Files - 4.1 Structure of Code - Rule 1

339


StructureOfCode3.ruleImplementation files in C++ should always have the file name extension ".cc".

OutputImplementation files in C++ should have the file name extension ".cc"




StructureOfCode4.ruleInline definition files always have the file extension ".icc"Reason for rule: Inline definition files - files which contain definitions of inline functions - should always have the file extension ".icc"

OutputInline definition files always have the file extension ".icc"




340


TypeConversionsPort1.ruleBe careful not to make type conversions from shorter type to longer type.

Examplevoid foo1() { int intValue; long longValue = 1L; longValue = intValue; // Violation}

void foo2() { int intValue=1; float floatValue; floatValue = intValue; // Violation}

OutputBe careful not to make type conversions from shorter type to longer type.



From: 18 Portable Code- 18.3 Type Conversions - Port. Rec. 6

TypeConversionsPort2.ruleBe careful not to make type conversions from a shorter type to a longer one.

Examplevoid foo3() {

int longValue = 1L;(double)longValue; // Violation

}

OutputBe careful not to make type conversions from a shorter type to a longer one.




341


TypeConversionsPort3.ruleAttempt to cast long value to double.Reason for rule: Under 32 bit platform double can hold all significant bits. Under 64 bit platform double has 52 significant bits, and bits can be lost.

Examplevoid moo (double) {}

void foo () { long longValue = 1L; moo(longValue); // Violation}

OutputAttempt to cast long value to double.




TypeConversionsPort4.ruleDo not cast a pointer as an int.Reason for rule: Do not assume that pointers and integers have the same size. All pointer casts to integer types should be either long or unsigned long.

Examplevoid foo(){ char *p; int g=(int)p; //Violation}

OutputDo not cast a pointer as an int.




342


Variables.ruleEach variable is to be declared in a separate declaration statement.Reason for rule: This rule checks for each function that the number of lines where a variable is declared is equal to the number of variables declared in that function. So it will trigger if some variables are declared on the same line.

Examplevoid foo() { // violation

int a,b;

}

void bar() { // Ok

int a; int b;

}

OutputEach variable is to be declared in a separate declaration statement.Variables : COUNT(A) Lines : COUNT(B)



From: 11 Variables - Rule 39

343

User MISRA Guidelines

Rule

ArrayIn eck-

AvoidA or

AvoidA s

AvoidD not ject

AvoidE y or

MISRA GuidelinesUser MISRA GuidelinesCodeWizard 4.3 includes a suite of rules to enforce requirements imposed by the Motor Industry Soft-ware Reliability Association (MISRA). These requirements can be found in the MISRA document "Guidelines For The Use Of The C Language In Vehicle Based Software.”

Note: All statically enforceable rules from the MISRA Guidelines document were implemented. These rules are implemented as:

• Built-in rules. Built-in MISRA rules are grouped under common prefix "misra.” For example "misra-20," "misra-112," and so on. The number corresponds to a number given to the rule in the original MISRA document. See “Built-in MISRA Guidelines” on page 89 for more informa-tion on the MISRA built-in rules included in CodeWizard.

• User rules. In this case the rules are prefixed with "user.” These rules are described in the fol-lowing table and rule sections. All these MISRA rules have numbers between 5001 and 5127; they were created by adding 5000 to the rule number taken from the original MISRA docu-ment. Therefore, MISRA rule 7 is identified by "user-5007.”

Important! What is the difference between Built-in MISRA rules and User MISRA rules?

• User MISRA rules, like all rules in the User category (including the Ellemtel rules), can be cus-tomized using RuleWizard.

• Built-in MISRA rules, along with the Effective C++, More Effective C++, Meyer-Klaus, and Uni-versal Coding Standard rules, cannot be altered using RuleWizard.

Some of the rules will need symbol information collected across multiple source files. For example, to verify that given symbol has only one definition, CodeWizard can analyze information collected from multiple sources, and issue a violation if more than a single definition was detected. To facilitate static analysis preformed on multiple files, a new command line tool (cwmfs) was introduced. See “CodeWiz-ard's cwmfs Utility” on page 127 for a detailed description of this new utility.

Since the MISRA guidelines focus on programs written in C, all MISRA rules are active for C code only. The ISO/IEC 9899:1999(E) standard for the C programming language was used as a reference when implementing the MISRA rules.

Tip! The MISRA Guidelines classify rules as "required" or "advisory." CodeWizard uses "Violation" and "Informational" severity levels for rules classified as "required" and "advisory," respectively.

RuleID Description

dexOutOfBounds 5004 Provisions should be made for appropriate run-time ching.

mbiguitiesWithDefinedOp 5100 Use only non-ambiguous forms of defined pre-processoperator.

ssignmentsInBooleanExp 5035 Assignment operators shall not be used in expressionwhich return Boolean value.

anglingRefsToLocals 5106 The address of an object with automatic storage shall be assigned to an object which may persist after the obhas ceased to exist.

xactEqualsNonEqualsOnFloats 5050 Floating point variables should not be tested for equalitinequality.

344


AvoidK nc-cifi-

AvoidN

AvoidN

AvoidR

AvoidS con-

AvoidS s

AvoidS

AvoidT

AvoidU

AvoidU age

AvoidU

BitWise te-

Boolea lue.

Casting -

Charac d

Confor e-

Consta t

Declare har

Declare

Declare less

Docum

Docum d

eyWordsAndTypesInMacros 5090 C macros shall only be used for symbolic constants, fution-like macros, type qualifiers and storage class speers.

onConstFunctionPointers 5104 Non-constant pointers to functions shall not be used.

onStandardCharsInInclude 5088 Non-standard characters shall not occur in header filenames in #include directives.

edundantExplicitCasts 5044 Redundant explicit casts should not be used.

ideEffectsInLogicalOp 5033 The right hand operand of a && or || operator shall not tain side effects.

izeofOnExpWithSideEffects 5040 The sizeof operator should not be used on expressionthat contain side effects.

witchWithNoCase 5064 Every switch statement shall have at least one case.

ooManyPPOpsInMacro 5098 There shall be at most one occurence of the # or ## pre-processor operators in a single macro definition.

naryMinusForUnsignedExp 5039 The unary minus operator shall not be applied to an unsigned expression.

nreachableCode1 5052 This rule is purely informational and will report a messwhen unreachable code in an if statement has been detected.

nreachableCode2 5052 There shall be no unreachable code.

OperationOnSignedInteger 5037 Bitwise operations shall not be performed on signed inger types.

nInSwitchExpression 5063 A switch expression should not represent a Boolean va

IntegralToFloat 5016 The underlying bit representations of floating point numbers shall not be used.

terMapping 5006 Values of character types shall be restricted to a defineand documented subset of ISO 10646-1.

mToIncludeDirectiveFormat 5089 The #include directive shall be followed by either a <filname> or "filename" sequence.

ntUnSignedExpression 5051 Evaluation of constant unsigned expression should nolead to wrap-around.

CharTypeExplicitly 5014 The type char shall always be declared as unsigned cor signed char.

FunctionsAtFileScope 5068 Functions shall always be declared at file scope.

ObjectsAtFunctionScope 5022 Declarations of objects should be at function scope una wider scope is necessary.

entIntegerDivision 5041 Document integer division

entUseOfPragmas 5099 All uses of #pragma directive shall be documented anexplained.

345


DoNotC

DoNotD ock.

DoNotH

DoNotI all

DoNotM not

DoNotM tion .

DoNotN

DoNotR hall

DoNotR hall

DoNotR

DoNotU m

DoNotU

DoNotU i-

DoNotU

DoNotU

DoNotU ters.

DoNotU

DoNotU s.

DoNotU eck-

DoNotU .

DoNotU .

DoNotU

DoNotU

DoNotU sed.

onfuseBitwise&LogicalOps 5036 Logical operators should not be confused with bitwise operators.

efineUndefineMacroInBlock 5091 Macros shall not be #define'd and #undef'd within a bl

ideGlobalVariables 5021 Do not hide names of global variables.

nitializeEnumMembers 5032 In enumerator list, the '=' construct shall not be used toexplicitly initialise members other than the first, unlessitems are explicitly initialized.

ixAssemblyAndC 5003 Assembly language functions that are called from C should be written as C functions containing only in-lineassembly language. In-line assembly language shouldbe embedded in normal C code.

odifyCounterInForLoopBody 5067 Numeric variables being used within a for loop for iteracounting should not be modified in the body of the loop

estComments 5009 Comments shall not be nested.

edefineReservedNames1 5114 Reserved words and standard library function names snot be redefined or undefined.

edefineReservedNames2 5114 Reserved words and standard library function names snot be redefined or undefined.

euseTypedefNames 5017 Typedef names shall not be reused.

seAbortExitGetenvSystem 5126 The library functions abort, exit, getenv and system frolibrary <stdlib.h> shall not be used.

seAtofAtoiAtol 5125 The library functions atof, atoi and atol from library <stdlib.h> shall not be used.

seBreakStatement 5058 The break statement shall not be used (except to termnate the case of a switch statement).

seContinueStatement 5057 The continue statement shall not be used.

seErrno 5119 The error indicator errno shall not be used.

seFloatsAsLoopCounters 5065 Floating point variables shall not be used as loop coun

seGotoStatement 5056 The goto statement shall not be used.

seLabels 5055 Labels should not be used, except in switch statement

seLeftShifts 5004 Provisions should be made for appropriate run-time ching.

seLocaleHAndSetLocale1 5121 <locale.h> and the setlocale function shall not be used

seLocaleHAndSetLocale2 5121 <locale.h> and the setlocale function shall not be used

seLongIdentifiers 5011 Identifiers shall not have more than 31 characters.

seOclatConstants 5019 Octal constants (other than zero) shall not be used.

seOffsetof 5120 The macro offsetof, in library <stddef.h>, shall not be u

346


DoNotU

DoNotU di-

DoNotU

DoNotU es.

DoNotU e

DoNotU

DoNotU pro-

DoNotU t be

DoNotU

DoNotU

DoNotU

DoNotU t be

DoNotU t be

DoNotU

Expres

Expres ny

Expres ny

Expres ny

Floatin -

Floatin -

FullySp fied.

Implici ma-

Implici ma-

sePointerArithmetic 5101 Pointer arithmetic should not be used.

seRecursion 5070 Functions shall not call themselves, either directly or inrectly.

seRegisterStorageClass 5028 The register storage class specifier shall not be used.

seRelationalOpsOnPointers 5103 Relational operators shall not be applied to pointer typ

seSetjmpAndLongjmp 5122 The setjmp macro and the longjmp function shall not bused.

seSignalH 5123 The signal handling facilities of <signal.h> shall not beused.

seStdioH 5124 The input/output library <stdio.h> shall not be used in duction code.

seTimeH 5127 The time handling functions of library <time.h> shall noused.

seTriGraphs 5007 Trigraphs shall not be used.

seUndef 5092 #undef should not be used.

seUnions 5109 Unions shall not be used.

seVariableNumberOfArgs1 5069 Functions with variable numbers of arguments shall noused.

seVariableNumberOfArgs2 5069 Functions with variable numbers of arguments shall noused.

seWideStringLiterals 5008 Wide string literals shall not be used.

sionEvaluation1 5046 Do not use the volatile keyword.

sionEvaluation2 5046 The value of an expression shall be the same under aorder of evaluation that the standard permits.



gInBitwiseExpressions1 5016 The underlying bit representations of floating point numbers shall not be used.

gInBitwiseExpressions2 5016 The underlying bit representations of floating point numbers shall not be used.

ecifyMembersOfStructOrUnion 5108 All members of structure or union should be fully speci

tConversionLosesInfo1 5043 Implicit conversions which may result in a loss of infortion shall not be used.

tConversionLosesInfo2 5043 Implicit conversions which may result in a loss of infortion shall not be used.

347


Include

Initializ n.

Invalid left

MakeD ssi-

MixedP to

MixedP to

MixedP to

MixedP to

NameB ed.

NullPo

NullPo

Pointer t be

PreferC Dis-f

PreferF like

Provide s in

Provide

Provide use.

Provide use.

Provide se.

Provide

PutNul

PutNul

Statements 5087 #include statements in a file shall only be preceded byother preprocessor directives or comments.

eVariablesAtDeclaration 5030 All automatic variables shall be initialized at declaratio

RangeOfShiftOperand 5038 The right hand operand of a shift operator shall lie between zero and one less than the width in bits of thehand operand (inclusive).

eclarationsStaticAtFileScope 5023 All declarations at file scope should be static where poble.

recisionArithmetic1 5048 Mixed precision arithmetic should use explicit casting generate the desired result.




itFields 5113 All the members of a structure (or union) shall be nam

interDereferenced1 5107 The NULL pointer shall not be dereferenced.

interDereferenced2 5107 The NULL pointer shall not be dereferenced.

NonPointerCast 5045 Type casting from any type to or from pointers shall noused.

onditionalCompilation 5010 Sections of old code should not be "commented out". abling of sections of code should be achieved by use oconditional compilation (e.g. #if or #ifdef constructs).

unctionsOverMacros 5093 A function should be used in preference to a function -macro.

AllOrNoneArgumentNames 5073 Identifiers shall either be given for all of the parametera function prototype declaration, or for none.

ExplicitReturnType 5075 Every function shall have an explicit return type.

FinalDefaultForSwitch1 5062 All switch statements should contain a final default cla

FinalDefaultForSwitch2 5062 All switch statements should contain a final default cla

FinalElseClause 5060 All if, else if constructs should contain a final else clau

SingleExitPointFromFunc 5082 A function should have a single point of exit.

lStatementsInTheirOwnLine1 5054 A null statement shall only occur on a line by itself, andshall not have any other text on the same line.

lStatementsInTheirOwnLine2 5054 A null statement shall only occur on a line by itself, andshall not have any other text on the same line.

348


ReturnExpres

rn

ReturnExpres

hall

Return d.

Termin all

TestErr or-

TooMa

TypesS

TypesS

TypesS

TypesS

Unions ger

UseBra e in

UseCo on-

UseCo and

UseCo ters at

UseCu

UseCu

UseCu

UseCu

UseCu

UseEm ty

UseExp

OfNonVoidFunctionMustHavesion

5083 For each function with non-void return value, each retushall have an expression.

OfVoidFunctionMustNotHavesion

5084 For functions with void return type, return statements snot have an expression.

ValueVoidShallNotBeUsed 5079 The values returned by void functions shall not be use

ateCaseWithBreak 5061 Every non-empty case clause in a switch statement shbe terminated with a break statement.

orInformation 5086 If a function return error information, then that error infmation should be tested.

nyPointerIndirectionLevels 5102 No more than two levels of pointer indirection shall beused.

uffixForNumericConstants1 5018 Numeric constants should be suffixed to indicate type,where an appropriate suffix is available.




AccessSubParts 5110 Unions shall not be used to access the sub-parts of lardata types.

cesToMatchStructure 5031 Braces shall be used to indicate and match the structurthe non-zero initialization of arrays and structures.

mmaInForLoopOnly 5042 The comma operator shall not be used, except in the ctrol expression of a for loop.

nsistentLinkage 5024 Identifiers shall not simultaneously have both internal external linkage in the same translation unit.

nstForArgsPassedByRef 5081 const qualification should be used on function paramewhich are passed by reference, where it is intended ththe function will not modify the parameter.

rlyBraces1 5059 Always use curly brackets after if statements.

rlyBraces2 5059 Always use curly brackets after else statements.

rlyBraces3 5059 Always use curly braces after for statement.

rlyBraces4 5059 Always use curly brackets after while statements.

rlyBraces5 5059 Always use curly brackets after do statement.

ptyParensForNoArgFunc 5085 Functions called with no parameters should have empparentheses.

licitTestsAgainstZero 5049 Test of a value against zero should be made explicit.

349


UseIde ara-es

UseIde ara-es

UseMin

UseOn t or

UsePar of a

UseThe the e

UseTyp le uld

UseVoi

VoidEx -

nticalTypesForDeclDef1 5072 For each function parameter the type given in the decltion and definition shall be identical, and the return typshall also be identical.

nticalTypesForDeclDef2 5072 For each function parameter the type given in the decltion and definition shall be identical, and the return typshall also be identical.

imalCharacterSet 5005 Only use characters defined in ISO C standard.

lyInstToDefineBit Fields 5111 Bit fields shall only be defined to be of type unsigned insigned int.

enthesesForMacroArgs 5096 In the definition of a function-like macro each instance parameter shall be enclosed in parentheses.

SameIdentifiersInDeclDef 5074 If identifiers are given for any of the parameters, then identifiers used in the declaration and definition shall bidentical.

edefsForBasicTypes 5013 The basic types of char, int, short, long, float and doubshould not be used, but specific-length equivalents shobe typedef'd for the specific compiler, and these type names used in the code.

dForFunctionsWith NoArgs 5076 Functions with no parameters shall be declared with parameter type void.

pressionsAsFunctionParameter 5080 Void expressions shall not be used as function parameters.

350


ArrayIndexOutOfBounds.ruleProvisions should be made for appropriate run-time checking.

Exampleint foo(int i) { int j[10];

return j[i]; /* Violation */}

int moo(int i) { int j; int k[10]; int l = k[j]; /* Violation */ int m;

/* OK */ if ((j < 10) && (j >= 0)) {

m = k[j]; } return 0;}

OutputEnsure that array indices are within the bounds of the array size before using them to index the array.

ReferenceOrigin: Misra Guidelines - Rule 4

351


AvoidAmbiguitiesWithDefinedOp.ruleUse only non-ambiguous forms of defined pre-processor operator.

Example// EXAMPLE.H - Example header file

#if defined TEST+1 // Violation#endif

#if defined TEST // OK#endif

#if defined EXAMPLE_H#endif

#if defined ( TEST ) // OK#endif

#if !defined ( EXAMPLE_H )#define EXAMPLE_H

class Example{};

#endif // !defined( EXAMPLE_H )

OutputThe defined pre-processor operator shall only be used in one of the two standards forms.


352


AvoidAssignmentsInBooleanExp.ruleAssignment operators shall not be used in expressions which return Boolean value.

Examplevoid foo() { int x; int y;

x=y; if ( x != 0) { // Ok // ... } if ( ( x=y) != 0) { // violation }

if ( x=y ) { // violation }

}

OutputAssignment operators shall not be used in expressions which return boolean value.


353


AvoidDanglingRefsToLocals.ruleThe address of an object with automatic storage shall not be assigned to an object which may persist after the object has ceased to exist.

Exampleint* globalvar;

int globalvar2;

void foo () { int x=0; globalvar=&x; // violation globalvar2=x; // ok}

OutputThe address of an object with automatic storage shall not be assigned to an object which may persist after the object has ceased to exist.


354


AvoidExactEqualsNonEqualsOnFloats.ruleFloating point variables should not be tested for equality or inequality.

Examplefloat bar1();double bar2();

void foo() { float f1,f2; double d1,d2;

if (f1==0) { // violation }

if (d1==0) { // violation }

if (f1!=0) { // violation }

if (d1!=0) { // violation }

if (f1==f2) { // violation }

if (f1!=f2) { // violation }

if (f1 >= 0) {} // ok if (d1 <= 0) {} // ok

if (bar1()==0) {} // violation if (bar2()!=0) {} // violation

if (bar1() > bar2()) {} // Ok

}

OutputFloating point variables should not be tested for equality or inequality.


355


AvoidKeyWords&TypesInMacros.ruleC macros shall only be used for symbolic constants, function-like macros, type qualifiers and storage class specifiers.In particular macros shall not be used to define statements or part of statements, nor to redefine the syntax of the language.

Example#define PI 3.1416 // Ok

#define PLUS2(X) ((X)+2) // Ok

#define SI_32 long // violation#define STARTIF if( // violation

OutputDo not redefine part of the language with macros.


AvoidNonConstFunctionPointers.ruleNon-constant pointers to functions shall not be used.

Examplevoid foo();

typedef void (*PFUNC) (void);

const PFUNC pf = foo; // ok

int bar() {

PFUNC f1; // violation

return 0;}

OutputNon-constant pointers to function shall not be used.


356


AvoidNonStandardCharsInInclude.ruleNon-standard characters shall not occur in header file names in #include directives.

Example

// incl\header.h:void foo();

// foo.cpp#include <sys\types.h>

#include "incl\header.h"

void foo(){}

OutputFilename $name should contain only standard characters.


357


AvoidRedundantExplicitCasts.ruleRedundant explicit casts should not be used.

Examplevoid foo44(){ char cVar = 1; cVar = (char) cVar; /* complain */ cVar = (char) (cVar+'e'); /* complain */ return;}

void foo44e(){ char cVar = 1; short sVar = 1; double dVar = 1.0;

dVar = (double) dVar; /* complain */ dVar = (double) (dVar * cVar + sVar); /* complain */ dVar = (double) (double)2/3; /* complain */ return;}

void foo44d(){ char cVar = 1; short sVar = 1; float fVar = 1.0;

fVar = (float) fVar; /* complain */ fVar = (float) (fVar * cVar + sVar); /* complain */ return;}

void foo44a(){ char cVar = 1; int iVar = 1; iVar = (int)iVar; /* complain */ iVar = (int)(iVar+60); /* complain */ iVar = (int)(iVar+cVar); /* complain */ return;}

358


void foo44b(){ char cVar = 1; int iVar = 1; long lVar = 1L; lVar = (long)lVar; /* complain */ lVar = (long)(lVar+60); /* complain */ lVar = (long)(lVar+iVar+cVar); /* complain */ return;}

void foo44f(){ char cVar = 1; short sVar = 1; long double ldVar = 1.0;

ldVar = (long double) ldVar; /* complain */ ldVar = (long double) (ldVar * cVar + sVar); /* complain */ ldVar = (long double) (long double)2/3; /* complain */ return;}

void foo44c(){ char cVar = 1; short sVar = 1; sVar = (short)sVar;/* complain */ sVar = (short)(sVar+cVar);/* complain */ return;}

OutputRedundant explicit casts should not be used.


359


AvoidSideEffectsInLogicalOp.ruleThe right hand operand of a && or || operator shall not contain side effects.

Exampleint foo1(int);

void foo2() { int ishigh=1; int x,i;

if (ishigh && ( x == i++)) {} // violation if (ishigh || ( x == foo1(x))) {} // violation }

OutputThe right-hand operand of a && or || operator shall not contain side effects.


AvoidSizeofOnExpWithSideEffects.ruleThe sizeof operator should not be used on expressions that contain side effects.Note: The Severity Level for this rule is Possible Violation.

Example

void foo() { int val = 1; sizeof(val); /*ok */ sizeof(val++); /* Violation */}

OutputThe sizeof operator should not be used on expressions that contain side effects.


360


AvoidSwitchWithNoCase.ruleEvery switch statement shall have at least one case.

Examplevoid foo(int i) { switch(i) /*Violation*/ { default: ; }}

OutputThere is no case clause in switch statement.


AvoidTooManyPPOpsInMacro.ruleThere shall be at most one occurence of the # or ## pre-processor operators in a single macro definition.

Example// Ok#define TEST(A,B) A # B

// Ok#define TEST2(A,B) A ## B

// violation#define TEST3(A,B,C) A # B # C

// violation#define TEST4(A,B,C) A ## B # C

// violation#define TEST5(A,B,C) A ## B ## C

OutputThere shall be at most one occurence of the # or ## pre-processor operator.


361


AvoidUnaryMinusForUnsignedExp.ruleThe unary minus operator shall not be applied to an unsigned expression.Note: The Severity Level for this rule is Informational.

Examplevoid foo() {int x;unsigned int sx;long z;unsigned long sz;

int res;

res = -x; // Ok

res = -sx; // Violation

long zres;

zres = -z; // Okzres = -sz; // Violation

}

OutputThe unary minus operator shall not be applied to an unsigned expression.


362


AvoidUnionsInDataStructures.ruleUnions shall not be used to access the sub-parts of larger data types.

Exampleunion NumericType // violation { int iValue; long lValue; double dValue; };

typedef union { // Violation char *a, b; float f[20];} TheUnion;

OutputDo not use unions.


363


AvoidUnreachableCode1.ruleThis rule is purely informational and will report a message when unreachable code in an if statement has been detected.


/* ... */


return;}

OutputUnreachable code detected.


AvoidUnreachableCode2.ruleThere shall be no unreachable code.

Exampleint foo (){ int i = 0;

return(i);

i = 7; /* Violation */}

OutputUnreachable code detected.


364


BitWiseOperationOnSignedInteger.ruleBitwise operations shall not be performed on signed integer types.

Exampleint goo() { return 0;}

void foo() { int dVar = 1; signed int sdVar = 0; unsigned int udVar = 0u; udVar = udVar & udVar; /* Ok */ udVar = udVar & dVar; /* Violation */ udVar = udVar & sdVar; /* Violation */ udVar ^= udVar; /* Ok */ udVar ^= dVar; /* Violation */ udVar ^= sdVar; /* Violation */ udVar ^= goo(); /* Violation */

unsigned int udVar2 = ~udVar; /* Ok */ unsigned int udVar3 = ~sdVar; /* Violation */ }

OutputFor all output: Bitwise operations shall not be performed on signed integer types.


365


BooleanInSwitchExpression.ruleA switch expression should not represent a Boolean value.Note: The Severity Level for this rule is Informational.

Examplevoid foo(int i) { switch(i) { case 0 : break; default: ; }}

void foo2(bool b) { switch(b) //Violation { case true : break; default: ; }}

OutputAll switch expression should not represent a Boolean value.


366


CastingIntegralToFloat.ruleThe underlying bit representations of floating point numbers shall not be used.

Example

void foo() {

int* pi; float* pf; double* pd;

pi = (int*)pf; /* violation */ pi = (int*)pd; /* violation */ pf = (float*)pd; /* OK */

short int* ps = (short*)pf; /* violation */ ps = (short*)pi; /* OK */ long* pl = (long*)pf; /* violation */}

OutputThe underlying bit representations of floating point numbers shall not be used in any way by the programmer.


367


CharacterMapping.ruleValues of character types shall be restricted to a defined and documented subset of ISO 10646-1.

Examplevoid foo() { const char * s[] = {"a", "\012" /* violation */ };}

OutputThe chosen implementation of C shall conform to a subset of ISO 10646-1, and the chosen subset shall be documented. Explicitly specified numerc value of character may not conform to chosen subset of ISO 10646-1.


ConformToIncludeDirectiveFormat.ruleThe #include directive shall be followed by either a <filename> or "filename" sequence.

Example

// Ok#include "misra89.h"

#define MISRA_HEADER "misra89.h"

// Violation:#include MISRA_HEADER

OutputThe #include directive shall be followed by either a <filename> or "file-name" sequence.


368


ConstantUnSignedExpression.ruleEvaluation of constant unsigned expression should not lead to wrap-around.

Example#if (1u - 2u)// ...#endif

OutputEvaluation of constant unsigned expressions should not lead to wrap-around. Because unsigned integer expressions do not strictly overflow, but instead wrap-around in a modular way, any constant unsigned integer expressions which in effect 'overflow' will not be detected by the compiler.


DeclareCharTypeExplicitly.ruleThe type char shall always be declared as unsigned char or signed char.

Example

typedef signed char SC;typedef unsigned char UC;typedef char CH;

void foo() {

char a; // violation signed char b; // ok unsigned char c; // ok

CH aa; // violation SC bb; // Ok UC cc; // Ok

}

void bar(char d); // violation

SC bar2(); // Ok

char bar3(); // violation

369


OutputFor $name, the type char shall always be declared as unsigned char or signed char.


DeclareFunctionsAtFileScope.ruleFunctions shall always be declared at file scope.

Examplevoid foo1() {}

void foo2() { void foo3(); // violation

}

OutputFunctions shall always be declared at file scope:


DeclareObjectsAtFunctionScope.ruleDeclarations of objects should be at function scope unless a wider scope is necessary.Note: The Severity Level for this rule is Informational.

Examplevoid foo() { int a; // OK}

int globalvar; // violation

OutputIf possible, do not use global variables.


370


DocumentIntegerDivision.ruleDocument integer division

Examplevoid foo1() { int i=2; int j=3; float f=4; float f2;

/* integer division */ f2=i/j; f2=j/i; /* Violation */ f2=f/i; /* OK - this is not integer division */}

OutputThe implementation of integer division in the chosen compiler should be determined, documented and taken into account. This rule checks that, wher-ever there is an integer division in the code, there must be comment on the previous line.


DocumentUseOfPragmas.ruleAll uses of #pragma directive shall be documented and explained.

Example#pragma TEST

OutputAll use of #pragma shall be documented and explained.


DoNotConfuseBitwise&LogicalOps.ruleLogical operators should not be confused with bitwise operators.To enforce this rule it is assumed that operands of logical operation must be of Boolean type. If the type is different, probably a bitwise operator should have been used in place the logical operator found.

Note: The Severity Level for this rule is Informational.

371


Exampletypedef int MY_INT;

char getSpace() { return ' ';}

bool getTrue() { return true;}

void foo() { int x=0; int y=0; bool b=false; bool b2=true; MY_INT myInt;

if (x || y) { // Violation }

if (b || b2) { // Ok } if (y++ || b) { // Violation }

if (b || getSpace()) { // Violation } if (b || getTrue()) { // Ok }

bool b3 = !x; // Violation bool b4 = !myInt; //Violation bool b5 = !b2; // Ok

}

OutputFor all outputs: type of operand is different like Boolean.


372


DoNotDefineUndefineMacroInBlock.ruleMacros shall not be #define'd and #undef'd within a block.

Example#define SUM(A,B) ((A)+(B)) // Ok

void foo(int* x) {

#define CHECKPARAM(p) (p != 0) // Violation

if (CHECKPARAM(x)) {/* ... */

}

#undef SUM // Violation

}

OutputMacros shall not be #define'd and #undef'd within a block.


DoNotHideGlobalVariables.ruleDo not hide names of global variables.

Exampleint x;

void foo(){ int x; /* Violation */ x = 3;}

OutputHid indentifier with identifier of the same name: LIST(C).


373


DoNotInitializeEnumMembers.ruleIn enumerator list, the '=' construct shall not be used to explicitly initialise members other than the first, unless all items are explicitly initialized.

Exampleenum TEST { /*Violation*/ X=5, Y, Z=9,};

enum TEST2 { /*Violation*/

X2, Y2=5, Z2,};

enum TEST3 { /*Ok*/ X3, Y3, Z3,};

enum TEST4 { /*Ok*/ X4=2, Y4, Z4,};

enum TEST5 { /*Ok*/

X5=2, Y5=4, Z5=8,};

OutputFor all outputs: incorrect members initialization.


374


DoNotMixAssemblyAndC.ruleAssembly language functions that are called from C should be written as C functions containing only in-line assembly language. In-line assembly language should not be embedded in normal C code.Note: The Severity Level for this rule is Informational.

Example/* compilable by cl.exe */

void asmCall(){ __asm{ mov eax, 01h int 10h }}

void asmCall2() /* complain */{ int g = 0; __asm{ mov eax, 01h int 10h }}

OutputDo not mix C code and assembler code in function body.


375


DoNotModifyCounterInForLoopBody.ruleNumeric variables being used within a for loop for iteration counting should not be modified in the body of the loop.Note: The Severity Level for this rule is Informational.

Examplevoid foo(){ int iVarA; int iVarB; char array[10]; for (iVarA=0; iVarA<=iVarB; iVarA++) { /* complain */ iVarA++; } for (array[iVarA]=0; array[iVarA] < 10; array[iVarA]++) { /* complain */ array[iVarB]--; } return;}

OutputModification of iterator in the loop's body.


DoNotNestComments.ruleComments shall not be nested.

Example

// c++ comment ok

/* C style comment ok */

/* comment shall not be nested violation here /* */

OutputComments shall not be nested.


376


DoNotRedefineReservedNames1.ruleReserved words and standard library function names shall not be redefined or undefined.

Example

// violation#define __LINE__ 12

// Violation#define break 1

OutputDo not redefine or undefine reserved words and standard names.


DoNotRedefineReservedNames2.ruleReserved words and standard library function names shall not be redefined or undefined.

Example

// ok#undef TEST

// violation:#undef __LINE__

// violation:#undef assert

OutputDo not redefine or undefine reserved words and standard names.


377


DoNotReuseTypedefNames.ruleTypedef names shall not be reused.

Example

// Violationtypedef char* Pchar;

typedef int MyInt;

void foo() { double MyInt;}

OutputTypedef names shall not be reused.


378


DoNotUseAbortExitGetenvSystem.ruleThe library functions abort, exit, getenv and system from library <stdlib.h> shall not be used.

Example#include <stdlib.h>

void foo( void ){ char *libvar;

libvar = getenv( "LIB" ); // violation

system("dir"); // violation

abort(); // violation

exit(0); // violation

}

OutputThe library functions abort, exit, getenv and system from library shall not be used.


379


DoNotUseAtofAtoiAtol.ruleThe library functions atof, atoi and atol from library <stdlib.h> shall not be used.

Example

#include <stdlib.h>

void foo( void ){ char *s; double x; int i; long l;

s = " -2309.12E-15"; x = atof( s ); // violation

s = " -9885 pigs"; i = atoi( s ); // violation

s = "98854 dollars"; l = atol( s ); // violation

}

OutputThe library functions atof, atoi and atol from the library <stdlib.h> shall not be used.


380


DoNotUseBreakStatement.ruleThe break statement shall not be used (except to terminate the case of a switch statement).

Examplevoid foo(){ while(true) { int i=0; while (true) { i++; if (i==10) { break; /*Violation*/ } } switch( i ) { case -1: while (true) { i++; if (i==10) { break; /*Violation*/ } } break; /*Ok*/ case 0 : break; /*Ok*/ default: break; /*Ok*/ } }}

OutputThe break statement shall not be used.


381


DoNotUseContinueStatement.ruleThe continue statement shall not be used.

Example

bool bar(int);void func(int i) { while(i--) { if (bar(i)) { continue; // Violation } }}

OutputThe continue statement shall not be used.


DoNotUseErrno.ruleThe error indicator errno shall not be used.

Example#include <errno.h>

void foo() {

errno=0; // violation

}

OutputThe error indicator errno shall not be used.


382


DoNotUseFloatsAsLoopCounters.ruleFloating point variables shall not be used as loop counters.

Examplevoid foo() {

for (float i=0.;10.;i++) { // violation // does soemthing }}

OutputFloating point variables shall not be used as loop counters.


DoNotUseGotoStatement.ruleThe goto statement shall not be used.

Examplevoid func(bool done) { if (done) { goto end; // violation} end: return; }

OutputThe goto statement shall not be used.


383


DoNotUseLabels.ruleLabels should not be used, except in switch statements.Note: The Severity Level for this rule is Informational.

Examplevoid foo(int count) {

//.. goto stop_operation; //...

stop_operation: return; //Violation

//.. }

OutputLabels should not be used, except in switch statements.


DoNotUseLeftShifts.ruleProvisions should be made for appropriate run-time checking.Note: The Severity Level for this rule is Informational.

Examplevoid main() { int i = 4; int j = 2; int k = j << i; /* Violation */}

OutputLeft shifting of an integer may cause the most significant bit(s) to be lost, effectively a kind of overflow.


384


DoNotUseLocaleHAndSetLocale1.rule<locale.h> and the setlocale function shall not be used.

Example#include <locale.h> // violation

void foo(void){

/* Set the locale back to the default environment */ setlocale(LC_ALL, "C"); // violation

}

OutputThe <locale.h> and the setlocale function shall not be used.


DoNotUseLocaleHAndSetLocale2.rule<locale.h> and the setlocale function shall not be used.

Example#include <locale.h> // violation

void foo(void){

/* Set the locale back to the default environment */ setlocale(LC_ALL, "C"); // violation

}

Output<locale.h> and the setlocale function shall not be used.


385


DoNotUseLongIdentifiers.ruleIdentifiers shall not have more than 31 characters.

Examplevoid foo(); // okvoid this_is_not_ok_11111111111111111(); // violationclass ThisClassHasANameThatIsTooBig11111{}; // violation

OutputIdentifiers shall not have more than 31 characters.


DoNotUseOclatConstants.ruleOctal constants (other than zero) shall not be used.

Examplevoid foo() { int code = 012; /*Violation*/ int code2 = 12; /*Ok*/

}

OutputOctal constants other than zero shall not be used.


386


DoNotUseOffsetof.ruleThe macro offsetof, in library <stddef.h>, shall not be used. Note: The CodeWizard option 'pproanalyze off' must be set to be able to enforce this rule.

Example

#include <stddef.h>

struct S{ int x, y, z; char buffer [128];};

int main(){ int i= offsetof( S, buffer); // Violation return 0;}

OutputThe macro offsetof shall not be used.


387


DoNotUsePointerArithmetic.rulePointer arithmetic should not be used.Note: The Severity Level for this rule is Informational.

Examplevoid foo() {

int* a; int* b;

int tab[10];

a=tab; a++; // violation --a; // violation

b = a+5; // violation

}

OutputFor all outputs: Pointer arithmetic shall not be used.


DoNotUseRecursion.ruleFunctions shall not call themselves, either directly or indirectly.Note: This rule only checks for direct recursion.

Examplevoid foo1(int l) { int x=l;

if (l > 0) { foo1(x-1); // violation }

}

void foo2() { // OK // empty}

388


void foo3(); // OK

void foo5(int);

void foo4(int l) {

int x=l;

if (l > 0) { foo5(x-1); // OK - cannot check indirect recursion }

}

void foo5(int l) {

int x=l;

if (l > 0) { foo4(x-1); // OK - cannot check indirect recursion }

}

void foo6() { foo2(); // OK}

OutputDo not use recursion.


389


DoNotUseRegisterStorageClass.ruleThe register storage class specifier shall not be used.Note: The Severity Level for this rule is Informational.

Examplevoid foo() {int a; // okregister int b; // violation

}

OutputThe register storage class specifier shall not be used.


DoNotUseRelationalOpsOnPointers.ruleRelational operators shall not be applied to pointer types.

Examplevoid foo() {

int* a; int* b;

int tab[10];

a=tab;

b = a+5;

if (a > b) { // violation } if ( b <= a) { // violation }

}

OutputPointer arithmetic shall not be used.


390


DoNotUseSetjmpAndLongjmp.ruleThe setjmp macro and the longjmp function shall not be used.

Example

#include <setjmp.h>

jmp_buf mark; /* Address for long jump to jump to */int fperr; /* Global error number */

void foo( void ){ int jmpret; jmpret = setjmp( mark ); // violation}

void fphandler( int sig, int num ){

longjmp( mark, -1 ); // violation}

Outputsetjmp macro and longjmp function shall not be used.


DoNotUseSignalH.ruleThe signal handling facilities of <signal.h> shall not be used.

Example#include <signal.h> // violation

OutputThe signal handling facilities of <signal.h> shall not be used.


391


DoNotUseStdioH.ruleThe input/output library <stdio.h> shall not be used in production code.

Example#include <stdio.h> // violation

OutputThe input/output library <stdio.h> shall not be used in production code.


DoNotUseTimeH.ruleThe time handling functions of library <time.h> shall not be used.

Example#include <time.h> // violation

OutputThe time handling functions of library <time.h> shall not be used.


392


DoNotUseTriGraphs.ruleTrigraphs shall not be used.

Example??=define TEST 1

void foo() { const char * s1 = "(Date should be in the form ??-??-??)"; /* violation */ const char * s2 = "(Date should be in the form ~~]";}

OutputAll occurrences in a source file of the following sequences of three charac-ters (called trigraph sequences) are replaced with the corresponding single character.??= #??( [??/ \??) ]??' ^??< {??! |??> }??- ~If the compiler has a switch to ignore trigraphs then this option should be used, or alternatively ensure that two adjacent question marks are never used in the code.


393


DoNotUseUndef.rule#undef should not be used.Note: The Severity Level for this rule is Informational.

Example#undef TEST

Output#undef should not be used.


DoNotUseUnions.ruleUnions shall not be used.

Exampleunion U1{ int _i; char _buf[sizeof(int)];};

OutputOverlapping variable storage shall not be used.


394


DoNotUseVariableNumberOfArgs1.ruleFunctions with variable numbers of arguments shall not be used.

Examplevoid foo(int, ...) { // Violation

}

OutputFunctions with variable numbers of arguments shall not be used.


DoNotUseVariableNumberOfArgs2.ruleFunctions with variable numbers of arguments shall not be used.

Example/* VA.C: The program below illustrates passing * a variable number of arguments using the * following macros: * va_start va_arg va_end * va_list va_dcl (UNIX only) */

#include <stdio.h>#define ANSI /* Comment out for UNIX version */#ifdef ANSI /* ANSI compatible version */#include <stdarg.h>int average( int first, ... );#else /* UNIX compatible version */#include <varargs.h>int average( va_list );#endif

void main( void ){ /* Call with 3 integers (-1 is used as terminator). */ printf( "Average is: %d\n", average( 2, 3, 4, -1 ) );

/* Call with 4 integers. */ printf( "Average is: %d\n", average( 5, 7, 9, 11, -1 ) );

/* Call with just -1 terminator. */ printf( "Average is: %d\n", average( -1 ) );}

395


/* Returns the average of a variable list of integers. */

#ifdef ANSI /* ANSI compatible version */int average( int first, ... ) // Violation{ int count = 0, sum = 0, i = first; va_list marker;

va_start( marker, first ); // Violation while( i != -1 ) { sum += i; count++; i = va_arg( marker, int); // Violation } va_end( marker ); // Violation return( sum ? (sum / count) : 0 );}

#else /* UNIX compatible version must use old-style definition. */int average( va_alist )va_dcl{ int i, count, sum; va_list marker;

va_start( marker ); // Violation for( sum = count = 0; (i = va_arg( marker, int)) != -1; count++ ) // Vio-lation sum += i; va_end( marker ); // Violation return( sum ? (sum / count) : 0 );}#endif

OutputFunctions with variable numbers of arguments shall not be used.


396


DoNotUseWideStringLiterals.ruleWide string literals shall not be used.

Example#include <stddef.h>

void foo() {

wchar_t* x = L"Fred"; // Violation

}

OutputWide strings literals shall not be used.


ExpressionEvaluation1.ruleDo not use the volatile keyword.

Example

void foo1() {

volatile int v; // violation

}

OutputDo not use the volatile keyword.


397


ExpressionEvaluation2.ruleThe value of an expression shall be the same under any order of evaluation that the standard permits.

Examplevoid foo46b() { int a = 0; int b = 0; a = ++a + b++; /* complain */ return;}

OutputUsing of complex expression is error-prone.



Examplevoid foo46c(){ int array[3] = {0}; int iVar = 1; array[iVar++] = iVar; /* complain */ return;}

OutputUsing of increment the variable in the context of table indexing.


398



Examplevoid foo46(){ int array[3] = {0}; int iVar = 1; array[iVar] = --iVar; /* complain */ return;}

OutputModification of the index in context of its using.


FloatingInBitwiseExpressions1.ruleThe underlying bit representations of floating point numbers shall not be used.

Examplevoid moo(int i,float f) {

float x,y; double d; long j; float k = x|i; /* violation */ k=j&i; /* OK */ int l; l=~d; /* violation */}



399


FloatingInBitwiseExpressions2.ruleThe underlying bit representations of floating point numbers shall not be used.

Examplevoid moo(int i,float f) {

float x,y; double d; long j; float k = x|i; /* violation */ k=j&i; /* OK */ int l; l=~d; /* violation */}



400


FullySpecifyMembersOfStructOrUnion.ruleAll members of structure or union should be fully specified.

Examplestruct Z { int z;};

/* violation */struct Y1 { struct X* p; struct Z* z; int i;};

/* OK */struct Y2 { struct Z* z; int i;};

OutputIn the specification of a structure or union type, all members of the struc-ture or union shall be fully specified.


401


ImplicitConversionLosesInfo1.ruleImplicit conversions which may result in a loss of information shall not be used.

Examplevoid foo() {

int a1,b1; float a2,b2;

if (a1>b1) {} // ok if (a1==b2) {} // violation if (a2!=b2) {} // ok

if (a1+(a2*b2) > a2) {} // violation

}

OutputLIST(A) # LIST(B)


402


ImplicitConversionLosesInfo2.ruleImplicit conversions which may result in a loss of information shall not be used.

Examplevoid foo2() {

signed int si; unsigned int ui;

ui=si; // violation si=ui; // violation }

OutputImplicit conversion which may result in a loss of information shall not be used.


IncludeStatements.rule#include statements in a file shall only be preceded by other preprocessor directives or comments.

Examplevoid foo();

int g;

#include "test.h"

void main() { }

OutputAll the #include statements in a particular code file should be grouped together near the head of the file. It is important to prevent the situa-tion of executable code coming before a #include directive, otherwise there is danger that the code may try to use items which would be defined in the header.


403


InitializeVariablesAtDeclaration.ruleAll automatic variables shall be initialized at declaration.

Examplevoid foo1() { int a; // violation int b=1; // ok int* ptr1; // ok}

OutputAll automatic variables shall be initialized at declaration.


InvalidRangeOfShiftOperand.ruleThe right hand operand of a shift operator shall lie between zero and one less than the width in bits of the left hand operand (inclusive).Note: This rule was prepared for 32 bit integer.

Examplevoid foo() { unsigned int uVal = 1u; uVal <<= 2; /* Ok */ uVal <<= 100; /* Violation */}

OutputBitwise operations shall not be performed on signed integer types.


404


MakeDeclarationsStaticAtFileScope.ruleAll declarations at file scope should be static where possible.Note: The Severity Level for this rule is Informational.

Examplestatic int g1; // Ok

int g2; // violation

void foo1() ; // violation

static void foo2(); // ok

OutputAll declarations at file scope should be static where possible.


MixedPrecisionArithmetic1.ruleMixed precision arithmetic should use explicit casting to generate the desired result.Note: The Severity Level for this rule is Informational.

Examplevoid foo48b(){ int iVar = 2; long lVar = 1; float fVar = 1.0; iVar = (((iVar==2) ? fVar : lVar) + 22); /* complain */ iVar = (((iVar==2) ? (int)fVar : (int)lVar) + 22); /* OK */

return;}

OutputNot all operators operate on the same data type.


405


MixedPrecisionArithmetic2.ruleMixed precision arithmetic should use explicit casting to generate the desired result.Note: The Severity Level for this rule is Informational.

Examplevoid foo48c(){ int iVar = 2; long lVar = 1; float fVar = 1.0; iVar = (((iVar==2) ? lVar : fVar ) + 22);

/* complain */ iVar = (((iVar==2) ? lVar : (int)fVar ) + 22);

/* OK */

return;}



406


MixedPrecisionArithmetic3.ruleMixed precision arithmetic should use explicit casting to generate the desired result.

Examplevoid foo48a(){ int iVar = 2; long lVar = 1; float fVar = 1.0; fVar -= lVar; /* complain */ fVar -= (float)lVar; /* OK */ return;}



MixedPrecisionArithmetic4.ruleMixed precision arithmetic should use explicit casting to generate the desired result.

Examplevoid foo48(){ int iVar = 2; long lVar = 1; float fVar = 1.0; fVar = lVar/iVar; /* complain */ fVar = 34 + (float)lVar/(float)iVar - 2; /* OK */ return;}



407


NameBitFields.ruleAll the members of a structure (or union) shall be named.

Exampletypedef signed int t;typedef int plain;struct tag { unsigned t:4; const t:5; /* violation */ plain r:5;};

OutputThe "bit field" facility in C is one of the most poorly defined parts of the language. There are two main uses to which bit-fields could be put:

1. To access individual bits, or group of bits, in larger data-types, in conjunction with unions (see rule 110).

2. To allow flags or other short-length data to be packed to save storage space. The packing together of short-length data to economise on storage is the only acceptable use of bit fields envisaged in this document.

Provided the elements of the structure are only ever accessed by their name, the programmer needs to make no assumptions about the way the bit fields are stored within the structure. This rules checks that all declared bit fields have names.


408


NullPointerDereferenced1.ruleThe NULL pointer shall not be dereferenced.


int* foo();

struct T{ int _i;};

void bar() {

int* p; int j; struct T * tPtr;

p = foo(); j=*p; /* violation */

if (p != 0) { j=*p; /* OK */ j= (*p) + 1; /* OK */ }

tPtr = malloc(sizeof(struct T)); tPtr->_i = 1; /* violation */ free(tPtr);}

OutputThe NULL pointer shall not be dereferenced.


409


NullPointerDereferenced2.ruleThe NULL pointer shall not be dereferenced.


int* foo();

struct T{ int _i;};

void bar() {

int* p; int j; struct T * tPtr;

p = foo(); j=*p; /* violation */

if (p != 0) { j=*p; /* OK */ j= (*p) + 1; /* OK */ }

tPtr = malloc(sizeof(struct T)); tPtr->_i = 1; /* violation */ free(tPtr);}

OutputThe NULL pointer shall not be dereferenced.


410


PointerNonPointerCast.ruleType casting from any type to or from pointers shall not be used.

Examplevoid foo45(){ char *cPtr = 0; int iVar = 0; void *vp = 0; cPtr = (char *)iVar; /* complain */ vp = (void *)iVar; /* complain */ return;}

void foo45a(){ int iVar = 0; short array[3] = {0}; iVar = (int)array; /* complain */ return;}

OutputUsing of casting a non-pointer type to a pointer type.


411


PreferConditionalCompilation.ruleSections of old code should not be "commented out". Disabling of sections of code should be achieved by use of conditional compilation (e.g. #if or #ifdef constructs).Note: The Severity Level for this rule is Informational.

Examplevoid foo() { int dVal = 5;

/* Violation *//* if (dVal==0) { //...code }*/

/* Ok */#if 0 if (dVal==0) { //...code }#endif}

OutputSection of code should not be 'commented out'.


PreferFunctionsOverMacros.ruleA function should be used in preference to a function -like macro.Note: The Severity Level for this rule is Informational.

Example#define PI 3.1416 // OK#define test() "this is a string" // OK

#define SUM(A,B) ((A)+(B)) // violation

OutputA function should be used in preference to a function-like macro.


412


ProvideAllOrNoneArgumentNames.ruleIdentifiers shall either be given for all of the parameters in a function prototype declaration, or for none.

Examplevoid foo(); // Ok

void foo1(int, int); // Ok

void foo2(int a, int b); // Ok

void foo3(int a, int); // Violation

void foo4(int a, int, int b); // Violation

OutputIdentifiers shall be given for all parameters, or none.


ProvideExplicitReturnType.ruleEvery function shall have an explicit return type.

Example/* compilable by cl.exe */

int goo(void); /*Ok*/foo(void); /*Violation*/

OutputEvery function shall have an explicit return type.


413


ProvideFinalDefaultForSwitch1.ruleAll switch statements should contain a final default clause.

Examplevoid foo(int i) { switch(i) /*Violation*/ { case 0 : i++; switch(i) { case 0 : break; default: ; }

case 1 : i++; break; }}

OutputThere is no default clause in switch statement.


ProvideFinalDefaultForSwitch2.ruleAll switch statements should contain a final default clause.

Examplevoid foo(int i) { switch(i) /*Violation*/ { case 0 : break; }}

OutputThere is no default clause in switch statement.


414


ProvideFinalElseClause.ruleAll if, else if constructs should contain a final else clause.Note: The Severity Level for this rule is Informational.

Examplevoid foo(int x){

if ( x < 0) { // ok // }

if ( x < 0) { // Ok // } else { // }

if ( x < 0) { // } else if (x > 0) { // Violation // } if ( x < 0) { // } else if (x > 0) { // Ok // } else { }

}

OutputAll if+else if constructs should contain a final else clause.


415


ProvideSingleExitPointFromFunc.ruleA function should have a single point of exit.Note: The Severity Level for this rule is Informational.

Exampleint foo1(int a) { // Violation if (a>0) { return 1; } else { return 0; }}

int foo2(int a) { // Ok int l; if (a>0) { l=1; } else { l=0; }

return l;

}

OutputA function should have a single point of exit.


416


PutNullStatementsInTheirOwnLine1.ruleA null statement shall only occur on a line by itself, and shall not have any other text on the same line.

Example

void foo() { /*Violation*/ int dVal;; }

OutputA null statement shall only occur on a line by itself.


PutNullStatementsInTheirOwnLine2.ruleA null statement shall only occur on a line by itself, and shall not have any other text on the same line.

Examplevoid foo(int dVal) { /*Violation*/ if (dVal==0) { ; /*Comment in this place is also violation*/ }

/*Ok*/ if (dVal==0) { ; }}

OutputA null statement shall only occur on a line by itself.


417


ReturnOfNonVoidFunctionMustHaveExpression.ruleFor each function with non-void return value, each return shall have an expression.

Example/* compilable by 'c' compiler */

void foo1() {

return; // Ok

}

int foo2() {

return ; // violation

}

int foo3() {

return 0; // ok

}

OutputEach return should have an expression.


418


ReturnOfVoidFunctionMustNotHaveExpression.ruleFor functions with void return type, return statements shall not have an expression.

Example/* compilable by 'c' compiler */

void foo1() { // Ok return;}

void foo2() { // violation return 1;}

void foo3() { // violation int a=0; return a;}

void foo4(int a) { // Violation return a;}

OutputIn function with void return type, return statement shall not have an expression.


419


ReturnValueVoidShallNotBeUsed.ruleThe values returned by void functions shall not be used.

Examplevoid foo();int moo();

void var() {

int j;

j=foo(); /* violation */

foo(); /* OK */

j=moo(); /* OK */

}

OutputThe values returned by void functions shall not be used.


420


TerminateCaseWithBreak.ruleEvery non-empty case clause in a switch statement shall be terminated with a break statement.

Examplevoid foo(int i) { switch(i) { case 0 : i++;/*Violation*/ case 1 :/*Ok*/ i++; break; case 3 :/*Ok (empty case)*/ case 4 : break; case 5: i++;/*Violation*/ default: ; }}

OutputEvery non-empty clause in a switch statement shall be terminated with a break statement.


421


TestErrorInformation.ruleIf a function return error information, then that error information should be tested.

Exampleint foo1();void foo2();int foo3();

void moo() { int i; i=foo1(); /* OK */ foo1(); /* violation */ (void)foo1(); /* OK */ foo2(); /* OK */

if (foo1()!=0) {} /* OK */ if (1) {

foo1(); /* violation */ } if (foo1()) {

foo3(); /* violation */ }

}

OutputThis rule assumes that error information is returned as function return value, any time return rype is integer, and it triggers when this return value is not somehow used.


422


TooManyPointerIndirectionLevels.ruleNo more than two levels of pointer indirection shall be used.Note: The Severity Level for this rule is Informational.

Exampleclass Test1 {private: int** x; // violation};

Test1** foo(); // violationTest1* foo(Test1** par); // violation

OutputNo more than two levels of pointer indirection shall be used.


TypesSuffixForNumericConstants1.ruleNumeric constants should be suffixed to indicate type, where an appropriate suffix is available.Note: The Severity Level for this rule is Informational.

Examplevoid foo18a(){ unsigned long lVar1 = 65537; /* complain */ unsigned long lVar2 = 65537L; /* OK */ return;}

OutputUnsigned long variable $name is initialized by signed constant out of range. Use "L" suffix.


423



Examplevoid foo18b() { unsigned long arrL[] = { /* complain */ 0, 1, 32767, 32768, 65535,

65536, 2147483547, 2147483648, 4294967295 };}

OutputUnsigned long variable is initialized by signed constant out of range. Use "L" suffix.



Examplevoid foo18(){ unsigned long lVar1 = 32768; /* complain */ unsigned long lVar2 = 32768U; /* OK */ return;}

OutputUnsigned long variable $name is initialized by signed constant out of range. Use "U" suffix.


424



Examplevoid foo18c() { unsigned long arrL[] = { /* complain */ 0, 1, 32767, 32768, 65535,

65536, 2147483547, 2147483648, 4294967295 };}

OutputUnsigned long variable is initialized by signed constant out of range. Use "u" or "U" suffix.


UseBracesToMatchStructure.ruleBraces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures.

Examplevoid test() {

int a[2][2] = {1,2,3,4}; // Violation int b[2][2] = { {1,2} , {3,4}}; // Ok}

OutputUse braces to indicate and match the structure in the non-zero initializa-tion of arrays and structures.


425


UseCommaInForLoopOnly.ruleThe comma operator shall not be used, except in the control expression of a for loop.

Examplevoid foo( int, int ); // Ok

void func() { for (int i = 0; i >=0, i < 10; i++) { // ok }} void func_one(int,int,int); // okvoid func_two(int,int); // ok

void bar() { int x,y,z;

func_one( x, y + 2, z ); // ok func_two( (x--, y + 2), z ); // violation

}

OutputThe comma operator should not be used, except in the control expression of a for statement.


426


UseConsistentLinkage.ruleIdentifiers shall not simultaneously have both internal and external linkage in the same translation unit.

Examplestatic unsigned short x;static unsigned short y;

void foo(){ extern unsigned short x; /* OK */ extern unsigned short y; /* same linkage a one visible at file scope */ { extern unsigned short y; /* complain */ }}

OutputVariables LIST(B) in the block scope does not have the same linkage as the prior declaration. Has external linkage.


427


UseConstForArgsPassedByRef.ruleconst qualification should be used on function parameters which are passed by reference, where it is intended that the function will not modify the parameter.Note: The Severity Level for this rule is Informational.

Examplevoid foo1(int x) { x +=1; // OK

}

void foo2(int& x) { x +=1; // OK

x=2;}

void foo3(const int& x) { int a; // OK a=x; }

void foo4(int& x) { int a; // violation a=x; }

OutputPass argument(s) LIST(D) with const specifier.


428


UseCurlyBraces1.ruleAlways use curly brackets after if statements.

Examplevoid foo2();

void foo(int x) {

if (x>0) {} // Ok // violation if (x>0) foo2();

// violation if (x>0) foo2(); else if (x < -1) { // ok } }

OutputAlways use curly brackets after if construction.


429


UseCurlyBraces2.ruleAlways use curly brackets after else statements.

Examplevoid foo2();

void foo(int x) {

if (x>0) foo2(); else if (x < -1) { // ok } // violation if (x >0) { } else foo2();}

OutputAlways use curly brace after else construction.


430


UseCurlyBraces3.ruleAlways use curly braces after for statement.

Examplevoid foo2();

void foo(int x) {

// violation for (int i=0; i< 10; i++) foo2();

// ok for (int j=0; j< 10; j++) {}

}

OutputAlways use curly braces after for construction.


UseCurlyBraces4.ruleAlways use curly brackets after while statements.

Examplevoid foo2();

void foo(int x) {

// ok while (x > 10) { }

// violation while (1) foo2();

}

OutputAlways use curly braces after while construction.


431


UseCurlyBraces5.ruleAlways use curly brackets after do statement.

Examplevoid foo2();

void foo(int x) { // violation do foo2(); while(1);

// Ok do { } while (1);

}

OutputAlways use curly brackets after do construction.


432


UseEmptyParensForNoArgFunc.ruleFunctions called with no parameters should have empty parentheses.Note: The Severity Level for this rule is Informational.

Exampleint foo85();

void foo() { int iVar = 0; if( foo85 == 0 ) { /* complain */ iVar++; } if( 0 == foo85 ) { /* complain */ iVar++; }}

OutputDo not use pointer to the function in condition expression.


433


UseExplicitTestsAgainstZero.ruleTest of a value against zero should be made explicit.Note: The Severity Level for this rule is Informational.

Examplevoid foo() { int x; if (x != 0) { // Ok }

if (!x) { // violation }

if (x) { // violation }}

OutputTest of a value against zero should be made explicit.


434


UseIdenticalTypesForDeclDef1.ruleFor each function parameter the type given in the declaration and definition shall be identical, and the return types shall also be identical.

Exampletypedef int MyInt;typedef MyInt MyInt2;typedef MyInt MyInt3;

class test{};

void foo0();

void foo2(int a, MyInt2 b); // Violationvoid foo2b(int a, float b);

void foo2c(test a, float b);void foo3(int a) {}

void foo2(int a, MyInt3 b) {}void foo2c(test a, float b){}

int bar2(); // ViolationMyInt bar2(){return 0;}

OutputParameter types in declaration and implementation of $function are differ-ent.


435


UseIdenticalTypesForDeclDef2.ruleFor each function parameter the type given in the declaration and definition shall be identical, and the return types shall also be identical.

Exampletypedef int MyInt;typedef MyInt MyInt2;typedef MyInt MyInt3;

class test{};

void foo0();

void foo2(int a, MyInt2 b); // Violationvoid foo2b(int a, float b);void foo2c(test a, float b);

void foo3(int a) {}

void foo2(int a, MyInt3 b) {}void foo2c(test a, float b){}

int bar2(); // ViolationMyInt bar2(){return 0;}

OutputReturn types in declaration and implementation of $function are different.


436


UseMinimalCharacterSet.ruleOnly use characters defined in ISO C standard.

Example#define test 1

void foo() { int i; char c='$'; /* violation */}

OutputOnly those characters and escape sequences which are defined in the ISO C standard shall be used.

Section 5.2.1 of the ISO C standards defines 91 characters which are the minimum source character set for all compilers. These are the only charac-ters that should be used, even if the compiler supports a larger character set, or supports alternative character sets. These characters are:

* The 26 uppercase letters of the Latin alphabet (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z)

* The 26 lowercase letters of the Latin alphabet (a b c d e f g h i j k l m n o p q r s t u v w x y z)

* The 10 decimal digits (0 1 2 3 4 5 6 7 8 9)

* The following 29 graphic characters (!"#%&' ()*+,-./:;<=>?[\]^_{|}~

* The space character, and control characters representing horizontal tab, vertical tab, and form feed.


437


UseOnlyInstToDefineBitFields.ruleBit fields shall only be defined to be of type unsigned int or signed int.

Exampleenum E_TAG { E1, E2};struct A1 { unsigned char f1:2; /* complain */

unsigned short f2:2; /* complain */ unsigned long f3:2; /* complain */ unsigned int f4:2; /* OK */ signed int f5:2; /* OK */ enum E_TAG f8:2; /* complain */

};

OutputOnly integral bit-fields are supported by the standard.


UseParenthesesForMacroArgs.ruleIn the definition of a function-like macro each instance of a parameter shall be enclosed in parentheses.

Example#define MULTI_2(x) (x*2) /*Violation*/#define MULTI_2(x) ((x)*2) /*Ok*/

OutputMissing parentheses.


438


UseTheSameIdentifiersInDeclDef.ruleIf identifiers are given for any of the parameters, then the identifiers used in the declaration and definition shall be identical.

Example

void foo1(); // Ok

void foo2(int a, int b); // Ok

void foo2(int a, int b) {}

void foo4(int , int ); // Ok

void foo4(int x, int y ) {}

void foo5(int a, int b); // Violation

void foo5(int x, int y ) {}

OutputIdentifiers given in declaration and definition of $function should be iden-tical.


439


UseTypedefsForBasicTypes.ruleThe basic types of char, int, short, long, float and double should not be used, but specific-length equivalents should be typedef'd for the specific compiler, and these type names used in the code.Note: The Severity Level for this rule is Informational.

Exampletypedef signed int SI;

void foo() { signed int c; // violation int a; // violation SI b; // ok}SI bar1(); // okdouble bar2() ; // violation

OutputFor $name, use typedef equivalent of char, int, short, long, float, double.


UseVoidForFunctionsWithNoArgs.ruleFunctions with no parameters shall be declared with parameter type void.

Examplevoid foo1(void); // OKvoid foo2(); // violation

OutputFunction $name with no parameter should be declared with parameter void.


440


VoidExpressionsAsFunctionParameter.ruleVoid expressions shall not be used as function parameters.

Examplevoid foo();

void moo1(int);void moo2(int,int);int goo();void bar () {

void *p; int a=0;

moo1(a); /* OK */ moo1(foo()); /* violation */ moo2(a,foo()); /* violation */ moo2(a,a); /* OK */ moo1(*p); /* violation */ moo1((void)goo()); /* violation */

}

OutputVoid expressions shall not be used as function parameters.


441

Legal Notices

Legal NoticesLegal NoticesMicrosoft Legal NoticeMicrosoft©, Visual C++®, and Visual Studio .NET® Integrated Development Environment (IDE) areeither registered trademarks or trademarks of Microsoft Corporation in the United States and/or othercountries.

PCRE Library Legal NoticePCRE is a library of functions to support regular expressions whose syntax and semantics are as closeas possible to those of the Perl 5 language.

Written by: Philip Hazel

University of Cambridge Computing Service,

Cambridge, England. Phone: +44 1223 334714.

Copyright (c) 1997-2003 University of Cambridge

Permission is granted to anyone to use this software for any purpose on any computer system, and toredistribute it freely, subject to the following restrictions:

1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULARPURPOSE.

2. The origin of this software must not be misrepresented, either by explicit claim or by omission.In practice, this means that if you use PCRE in software which you distribute to others, com-mercially or otherwise, you must put a sentence like this

"Regular expression support is provided by the PCRE library package, which is open sourcesoftware, written by Philip Hazel, and copyright by the University of Cambridge, England."

somewhere reasonably visible in your documentation and in any relevant files or online helpdata or similar. A reference to the ftp site for the source, that is, to ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ should also be given in the documentation.

3. Altered versions must be plainly marked as such, and must not be misrepresented as beingthe original software.

4. If PCRE is embedded in any software that is released under the GNU General PurposeLicence (GPL), or Lesser General Purpose Licence (LGPL), then the terms of that licence shallsupersede any condition above with which it is incompatible.

The documentation for PCRE, supplied in the "doc" directory, is distributed under the sameterms as the software itself.

442

Legal Notices

Parsifal XML Parser Legal NoticeParsifal XML Parser Copyright (c) 2002-2003.Toni Uusitalo released to the public domain 2002-11-15.

Parsifal is free for both commercial and non-commercial use and redistribution, provided that author'scopyright and disclaimer are retained intact. You are free to modify Parsifal for your own use and toredistribute Parsifal with your modifications, provided that the modifications are clearly documented.

DISCLAIMER ---------- This program is distributed in the hope that it will be useful, but WITHOUT ANYWARRANTY; without even the implied warranty of Merchantability or fitness for a particular purpose.Please use it AT YOUR OWN RISK.

Apache Software Foundation Legal NoticeThe Apache Software License, Version 1.1. Copyright (c) 1999-2001. The Apache Software Founda-tion. All rights reserved. Redistribution and use in source and binary forms, with or without modifica-tion, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditionsand the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditionsand the following disclaimer in the documentation and/or other materials provided with the dis-tribution.

3. The end-user documentation included with the redistribution, if any, must include the followingacknowledgment:

"This product includes software developed by the Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowledgment may appear in the software itself, if andwherever such third-party acknowledgments normally appear.

4. The names "Xerces" and "Apache Software Foundation" must not be used to endorse or pro-mote products derived from this software without prior written permission. For written permis-sion, please contact [email protected].

5. Products derived from this software may not be called "Apache", nor may "Apache" appear intheir name, without prior written permission of the Apache Software Foundation.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY ANDFITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHESOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOTLIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OFLIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCEOR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IFADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

====================================================

This software consists of voluntary contributions made by many individuals on behalf of the ApacheSoftware Foundation and was originally based on software copyright (c) 1999, International BusinessMachines, Inc., http://www.ibm.com. For more information on the Apache Software Foundation,please see <http://www.apache.org/>.

443

Legal Notices

Python Library Legal NoticeA. HISTORY OF THE SOFTWAREPython was created in the early 1990s by Guido van Rossum at StichtingMathematisch Centrum (CWI,see http://www.cwi.nl) in the Netherlands as a successor of a language called ABC. Guido remainsPython's principal author, although it includes many contributions from others.

In 1995, Guido continued his work on Python at the Corporation for National Research Initiatives(CNRI, see http://www.cnri.reston.va.us) in Reston, Virginia where he released several versions of thesoftware.

In May 2000, Guido and the Python core development team moved to BeOpen.com to form theBeOpen PythonLabs team. In October of the same year, the PythonLabs team moved to Digital Cre-ations (see http://www.digicool.com). In 2001, the Python Software Foundation (PSF, see http://www.python.org/psf/) was formed, a non-profit organization created specifically to own Python-relatedIntellectual Property. Digital Creations is a sponsoring member of the PSF.

All Python releases are Open Source (see http://www.opensource.org for the Open Source Definition).Historically, most, but not all, Python releases have also been GPL-compatible; the table below sum-marizes the various releases.

Footnotes:

1. GPL-compatible doesn't mean that we're distributing Python under the GPL. All Pythonlicenses, unlike the GPL, let you distribute a modified version without making your changesopen source. The GPL-compatible licenses make it possible to combine Python with othersoftware that is released under the GPL; the others don't.

Thanks to the many outside volunteers who have worked under Guido's direction to makethese releases possible.

Release Derived from Year Owner GPL-compatible?

0.9.0 thru 1.2 1991-1995 CWI yes

1.3 thru 1.5.2 1.2 1995-1999 CNRI yes

1.6 1.5.2 2000 CNRI no

2.0 1.6 2000 BeOpen.com no

1.6.1 1.6 2001 CNRI no

2.1 2.0+1.6.1 2001 PSF no

2.0.1 2.0+1.6.1 2001 PSF yes

2.1.1 2.1+2.0.1 2001 PSF yes

2.2 2.1.1 2001 PSF yes

444

Legal Notices

B. TERMS AND CONDITIONS FOR ACCESSING OR OTHERWISEUSING PYTHON

PSF LICENSE AGREEMENT FOR PYTHON 2.2

1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and theIndividual or Organization ("Licensee") accessing and otherwise using Python 2.2 software insource or binary form and its associated documentation.

2. Subject to the terms and conditions of this License Agreement, PSF hereby grants Licensee anonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or dis-play publicly, prepare derivative works, distribute, and otherwise use Python 2.2 alone or inany derivative version, provided, however, that PSF's License Agreement and PSF's notice ofcopyright, i.e., "Copyright (c) 2001 Python Software Foundation; All Rights Reserved" areretained in Python 2.2 alone or in any derivative version prepared by Licensee.

3. In the event Licensee prepares a derivative work that is based on or incorporates Python 2.2or any part thereof, and wants to make the derivative work available to others as providedherein, then Licensee hereby agrees to include in any such work a brief summary of thechanges made to Python 2.2.

4. PSF is making Python 2.2 available to Licensee on an "AS IS" basis. PSF MAKES NO REP-RESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUTNOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WAR-RANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE ORTHAT THE USE OF PYTHON 2.2 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.

5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON 2.2 FORANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULTOF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 2.2, OR ANY DERIVA-TIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

6. This License Agreement will automatically terminate upon a material breach of its terms andconditions.

7. Nothing in this License Agreement shall be deemed to create any relationship of agency, part-nership, or joint venture between PSF and Licensee. This License Agreement does not grantpermission to use PSF trademarks or trade name in a trademark sense to endorse or promoteproducts or services of Licensee, or any third party.

8. By copying, installing or otherwise using Python 2.2, Licensee agrees to be bound by theterms and conditions of this License Agreement.

445

Legal Notices

C. BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0

BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 11. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an office at 160

Saratoga Avenue, Santa Clara, CA 95051, and the Individual or Organization ("Licensee")accessing and otherwise using this software in source or binary form and its associated docu-mentation ("the Software").

2. Subject to the terms and conditions of this BeOpen Python License Agreement, BeOpenhereby grants Licensee a non-exclusive, royalty-free, world-wide license to reproduce, ana-lyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwiseuse the Software alone or in any derivative version, provided, however, that the BeOpenPython License is retained in the Software, alone or in any derivative version prepared by Lic-ensee.

3. BeOpen is making the Software available to Licensee on an "AS IS" basis. BEOPEN MAKESNO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAM-PLE, BUT NOT LIMITATION, BEOPEN MAKES NO AND DISCLAIMS ANY REPRESENTA-TION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULARPURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT INFRINGE ANY THIRDPARTY RIGHTS.

4. BEOPEN SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE SOFT-WARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS ASA RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY DERIV-ATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

5. This License Agreement will automatically terminate upon a material breach of its terms andconditions.\

6. This License Agreement shall be governed by and interpreted in all respects by the law of theState of California, excluding conflict of law provisions. Nothing in this License Agreementshall be deemed to create any relationship of agency, partnership, or joint venture betweenBeOpen and Licensee. This License Agreement does not grant permission to use BeOpentrademarks or trade names in a trademark sense to endorse or promote products or servicesof Licensee, or any third party. As an exception, the "BeOpen Python" logos available at http://www.pythonlabs.com/logos.html may be used according to the permissions granted on thatweb page.

7. By copying, installing or otherwise using the software, Licensee agrees to be bound by theterms and conditions of this License Agreement.

446

Legal Notices

D. CNRI LICENSE AGREEMENT FOR PYTHON 1.6.11. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives,

having an office at 1895 Preston White Drive, Reston, VA 20191 ("CNRI"), and the Individualor Organization ("Licensee") accessing and otherwise using Python 1.6.1 software in source orbinary form and its associated documentation.

2. Subject to the terms and conditions of this License Agreement, CNRI hereby grants Licenseea nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/ordisplay publicly, prepare derivative works, distribute, and otherwise use Python 1.6.1 alone orin any derivative version, provided, however, that CNRI's License Agreement and CNRI'snotice of copyright, i.e., "Copyright (c) 1995-2001 Corporation for National Research Initiatives;All Rights Reserved" are retained in Python 1.6.1 alone or in any derivative version preparedby Licensee. Alternately, in lieu of CNRI's License Agreement, Licensee may substitute thefollowing text (omitting the quotes): "Python 1.6.1 is made available subject to the terms andconditions in CNRI's License Agreement. This Agreement together with Python 1.6.1 may belocated on the Internet using the following unique, persistent identifier (known as a handle):1895.22/1013. This Agreement may also be obtained from a proxy server on the Internet usingthe following URL: http://hdl.handle.net/1895.22/1013".

3. In the event Licensee prepares a derivative work that is based on or incorporates Python 1.6.1or any part thereof, and wants to make the derivative work available to others as providedherein, then Licensee hereby agrees to include in any such work a brief summary of thechanges made to Python 1.6.1.

4. CNRI is making Python 1.6.1 available to Licensee on an "AS IS" basis. CNRI MAKES NOREPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE,BUT NOT LIMITATION, CNRI MAKES NO AND DISCLAIMS ANY REPRESENTATION ORWARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE ORTHAT THE USE OF PYTHON 1.6.1 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.

5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON 1.6.1FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS ARESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 1.6.1, ORANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

6. This License Agreement will automatically terminate upon a material breach of its terms andconditions.

7. This License Agreement shall be governed by the federal intellectual property law of theUnited States, including without limitation the federal copyright law, and, to the extent suchU.S. federal law does not apply, by the law of the Commonwealth of Virginia, excluding Vir-ginia's conflict of law provisions. Notwithstanding the foregoing, with regard to derivative worksbased on Python 1.6.1 that incorporate non-separable material that was previously distributedunder the GNU General Public License (GPL), the law of the Commonwealth of Virginia shallgovern this License Agreement only as to issues arising under or with respect to Paragraphs 4,5, and 7 of this License Agreement. Nothing in this License Agreement shall be deemed tocreate any relationship of agency, partnership, or joint venture between CNRI and Licensee.This License Agreement does not grant permission to use CNRI trademarks or trade name in atrademark sense to endorse or promote products or services of Licensee, or any third party.

8. By clicking on the "ACCEPT" button where indicated, or by copying, installing or otherwiseusing Python 1.6.1, Licensee agrees to be bound by the terms and conditions of this LicenseAgreement.

447

Legal Notices

E. CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2Copyright (c) 1991 - 1995, Stichting Mathematisch Centrum Amsterdam, The Netherlands. All rightsreserved.

Permission to use, copy, modify, and distribute this software and its documentation for any purposeand without fee is hereby granted, provided that the above copyright notice appear in all copies andthat both that copyright notice and this permission notice appear in supporting documentation, and thatthe name of Stichting Mathematisch Centrum or CWI not be used in advertising or publicity pertainingto distribution of the software without specific, written prior permission.

STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO THISSOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, INNO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE FOR ANY SPECIAL, INDI-RECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROMLOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OROTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PER-FORMANCE OF THIS SOFTWARE.

JPython .jar file (Python implementation for Java)Legal NoticeHISTORY OF THE SOFTWAREJPython was created in late 1997 by Jim Hugunin. Jim was also the primary developer while he was atCNRI. In February 1999 Barry Warsaw took over as primary developer and released JPython version1.1. In October 2000 Barry helped move the software to SourceForge where it was renamed to Jython.Jython is developed by a group of volunteers.

The standard library is covered by the BeOpen / CNRI license. See the Lib/LICENSE file for details.

The oro regular expresion matcher is covered by the apache license. See the org/apache/LICENSE filefor details.

The zxJDBC package was written by Brian Zimmer and originally licensed under the GNU PublicLicense. The package is now covered by the Jython Software License.

Jython Changes Software License.Copyright (c) 2000, Jython Developers. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted providedthat the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditionsand the following disclaimer.

2. Redistributions in binary form must reproduce the above copy right notice, this list of conditionsand the following disclaimer in the documentation and/or other materials provided with thedistribution.

3. Neither the name of the Jython Developers nor the names of its contributors may be used toendorse or promote products derived from this software without specific prior written permis-sion.

448

Legal Notices

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS''AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THEIMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSEARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FORANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAM-AGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SER-VICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVERCAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, ORTORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OFTHIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

JPython Software License.IMPORTANT: PLEASE READ THE FOLLOWING AGREEMENT CARE FULLY. BY CLICKING ONTHE "ACCEPT" BUTTON WHERE INDICATED, OR BY INSTALLING, COPYING OR OTHERWISEUSING THE SOFTWARE, YOU ARE DEEMED TO HAVE AGREED TO THE TERMS AND CONDI-TIONS OF THIS AGREEMENT.

JPython version 1.1.x1. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives,

having an office at 1895 Preston White Drive, Reston, VA 20191 ("CNRI"), and the Individualor Organization ("Licensee") accessing and using JPython version 1.1.x in source or binaryform and its associated documentation as provided herein ("Software").

2. Subject to the terms and conditions of this License Agreement, CNRI hereby grants Licenseea non-exclusive, non-transferable, royalty-free, world-wide license to reproduce, analyze, test,perform and/or display publicly, prepare derivative works, distribute, and otherwise use theSoftware alone or in any derivative version, provided, however, that CNRI's License Agree-ment and CNRI's notice of copyright, i.e., "Copyright ©1996-1999 Corporation for NationalResearch Initiatives; All Rights Reserved" are both retained in the Software, alone or in anyderivative version prepared by Licensee.

Alternatively, in lieu of CNRI's License Agreement, Licensee may substitute the followingtext (omitting the quotes), provided, however, that such text is displayed prominently in theSoftware alone or in any derivative version prepared by Licensee: "JPython (Version 1.1.x) ismade available subject to the terms and conditions in CNRI's License Agreement. This Agree-ment may be located on the Internet using the following unique, persistent identifier (known asa handle): 1895.22/1006. The License may also be obtained from a proxy server on the Webusing the following URL: http://hdl.handle.net/1895.22/1006."

3. In the event Licensee prepares a derivative work that is based on or incorporates the Softwareor any part thereof, and wants to make the derivative work available to the public as providedherein, then Licensee hereby agrees to indicate in any such work, in a prominently visible way,the nature of the modifications made to CNRI's Software.

4. Licensee may not use CNRI trademarks or trade name, including JPython or CNRI, in a trade-mark sense to endorse or promote products or services of Licensee, or any third party. Lic-ensee may use the mark JPython in connection with Licensee's derivative versions that arebased on or incorporate the Software, but only in the form "JPython-based___________________," or equivalent.

449

Legal Notices

5. CNRI is making the Software available to Licensee on an "AS IS" basis. CNRI MAKES NOREPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE,BUT NOT LIMITATION, CNRI MAKES NO AND DISCLAIMS ANY REPRESENTATION ORWARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE ORTHAT THE USE OF THE SOFTWARE WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.

6. CNRI SHALL NOT BE LIABLE TO LICENSEE OR OTHER USERS OF THE SOFTWAREFOR ANY INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES OR LOSS AS ARESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY DERIV-ATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. SOME STATESDO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY SO THE ABOVE DIS-CLAIMER MAY NOT APPLY TO LICENSEE.

7. This License Agreement may be terminated by CNRI (i) immediately upon written notice fromCNRI of any material breach by the Licensee, if the nature of the breach is such that it cannotbe promptly remedied; or (ii) sixty (60) days following notice from CNRI to Licensee of a mate-rial remediable breach, if Licensee has not remedied such breach within that sixty-day period.

8. This License Agreement shall be governed by and interpreted in all respects by the law of theState of Virginia, excluding conflict of law provisions. Nothing in this Agreement shall bedeemed to create any relationship of agency, partnership, or joint venture between CNRI andLicensee.

9. By clicking on the "ACCEPT" button where indicated, or by installing, copying or otherwiseusing the Software, Licensee agrees to be bound by the terms and conditions of this LicenseAgreement.

450

IndexIndex

Symbols#pragma and suppressions 25

AAction field 21

CC rules 170class field 23CodeWizard

customizing options 30customizing results 19installing 3using 10

coding standardscustom 17definition 1enforced 48

compilers supported 2configuration files 30contacting Parasoft 9

Eeditor, selecting 46embedded development 1, 13

Ffile field 23

IInsra 42–47

troubleshooting 46installation 3item field 22

LLicenseServer 6

Mmakefile 12metrics 169meyer-klaus rules 130miscellaneous rules 169misra built-in rules 89misra user rules 344

Nnaming conventions 169notes field 24

Ooracle proc files, see proc files

PParasoft, contacting 9Persistence field 21platforms supported 2proc files, codewizard support of 29psrc options 30

451

Qquality consulting 9

Rresults 11, 42

customizing 19rules

32 to 64 bit porting 170additional effective C++ 80built-in misra rules 89C 170effective C++ 49metrics 169meyers-klaus 130miscellaneous 169naming conventions 169telecom 269text 169universal coding standards 133user misra rules 344user rules 169

RuleWizard 17

Ssource, viewing 46suppressions 19, 45

adding 21and #pragma 25control panel 21, 27deleting 25example 27explanation 19moving 25saving 25

Ttechnical support 9telecom rules 269text rules 169type field 22

Uuniversal coding standards 133user rules 169

Vviolation messages

deleting 45saving/loading 46suppressing 19viewing 11, 42

452

user’s guide - massachusetts institute of technology · pdf fileiii parasoft end user...

Documents