C coding standards

}

}

5.7 The '?:' Construct (1100.1200.10.5)

Except in macros, the '

?:

'Construct Is Not ALLOWED

For logic control.

WHEN USED in in-line Source Code,

The '

?:

'Construct Be Can buy in Either

An Assignment Statement,

a

Return

STATEMENT,

or when passing parameters to a caled function.when buy in a c macro,

Nesting of the construct is left

To The Discretion of the Programmer,

Otherwise,

The Must Not Be Nested.

Bad Coding Practice:

A_PTR = (Nitems == 0)? Malloc ()

: Realloc (A_PTR, );

Good Coding Practice:

IF (NItems == 0)

{

A_PTR = Malloc ();

}

Else

{

A_PTR = Realloc (PTR, );

}

5.8 Unions (1100.1200.10.5)

When Using

union

S,

It is the programer's responsibility to keep track

Of which data type is currently store

union

.

Among Other Things this Can Be Done by Defeing a Variable To Track

The Last Data Type Stored in The Last Data Type

union

Al by Embedding

THE

union

Withnin a structure and defining a member within

The Same Structure Which Serves as a tag to track the

Last Data Type Stored in The

union

.

The Following Is An Example of The Second Alternative.

The structure member

"Type"

Serves as a tag to

TRACK The Last Data Type Stored in The Structure Member

"Variant"

Which is defined to becom

union

:

/ * Define the node type. * /

Typedef enum exfacttype {

Unary,

Binary,

Leaf,

} ExNodetyPE;

/ * Define a node. * /

Typedef struct exNode {

ExNodetype Type; / * Variant Tag * /

Union {

Struct {

/ * Pointer to Left Node * /

EXNODE * LEFT_PTR;

} unary;

Struct {

/ * Pointer to Left Node * /

EXNODE * LEFT_PTR;

/ * Pointer to Right Node * /

EXNODE * RIGHT_PTR;

} binary;

Struct {

Short info; / * Leaf data * /

LEAF;

Variant;

} ExNode;

5.9 Bit Manipulation (1100.1200.10.5)

Bit Fields Offer The Capability Of Defining

And Accessing Adjacent Bits Withnin A Word Directly,

Rather Than Bitwise and Shift Operators

(See Section 10.6.4).

Although Bit Fields Provide Direct Access,

Bit Manipulation Using Bitwise and Shift Operators

May Be more conducive for looping.

Consider The Following Example Which Packs A

Sequence of 4-bit BCD Digits Into a Single 32-Bit Word:

/ * Define bit Field size of bcd digit. * /

#define bfbcddig 4

Value = 0;

For (i = 0; i

{

Value | = (STR [I] - '0') << ((NUMDIG - I - 1) * bfbcddig);

}

Almost Everything About Bit Fields Is Implementation Dependent.

For example,

They is assigned left to right on some machines and right to leave

On On Others.

Consesequently,

Although Bit Fields Are Useful

For Maintaining Internal-Defined Data,

The Question of Which End Comes First Must Be Carefully Considered

When DEALING WIXTERLY-Defined Data.

Programs That Depend On Such Details Are Not Portable.

The underlying data type of a bit field shouth be each esthar

An Appropriate

ENUM

Type or an

unsigned

TYPE.

The size of a bit Field Should Be a

#define

CONSTANT

5ss only).

Consider the folowing example in which

a process id is packed INTO AN

Unsigned long

Data Type.

The process ID is Made Up of Three Values:

A Process Number,

a Processor ID,

And a uniqueness value.

Bad Coding Practice:

/ * Define Masks for Components Of Process ID. * /

#define exmsk_procno 0xffff

#define exmsk_pcrid 0xff

#define exmsk_uniq 0xff

/ * Define Bit Offsets for Components Of Process ID. * /

#define EXLSB_PROCNO 0

#define EXLSB_PCRID 16

#define EXLSB_UNIQ 24

/ * BAD PRACTICE * /

/ * Extract components of process ID. * /

Procno = (Procid >> EXLSB_PROCNO) & Exmsk_Procno;

PCRID = (Procid >> EXLSB_PCRID) & exmsk_pcrid;

UNIQ = (Procid >> EXLSB_UNIQ) & exmsk_uniq;

Good Coding Practice:

/ * Define bit Field SIZES * /

#define bfprocno 16

#define bfpcrid 8

#define bfuniq 8

Typedef struct exprocid {

Unsigned long procno: bfProcno;

Unsigned long PCRID: BFPCRID;

UNSIGNED Long Uniq: bfuniq;

} Exprocid;

EXPROCID PROCID;

Good Coding Practice:

/ * Extract components of process ID. * /

Procno = procid.procno;

PCRID = procid.pcrid;

UNIQ = procid.uniq;

5.10 DATA TYPES (1100.1200.10.5)

Data Types Should Be Chosen to Give An Accurate Description

Of the data being defined.

Two Logically Similar Items Should Use the Same

Typedef

.

Two Logically DiffERENT ITEMS

SHOULD USE DIFFERENT

Typedef

S,

Even if They has the Same Range of values.

ENUM

S Should Be Used to Define Values

Whose logical meanings are more important tour

The Actual Numbers Used to Represent Them.

For Example, The Logical Value of A Signal,

WHETHER IT IS onHOOK, OFFHOOK OR FLASH,

Is More Important Than The Actual Numbers

Which represent these values.

5.11 Source Featuring (1100.1200.10.5)

Source featuring is a component of the extended Change

Management System (ECMS)

That permits the definition and maintenance of

Different, Concurrent Versions of Source Files within

The Same Ecms Generic Release. It is buy

Isolate and maintain (in a given software release) functionality That IS

Required by some software refreases and not by tahers.

For Example, Featuring Can Be buy isolate Functionality Between

Software Release 5E4 (2) and 5ee3.

Feature Names Are Defined (by The ECMS Administrator) in The ECMS RELATION GPF

For Each ECMS Generic and Project. It is the developer's responibility

TO BE AWARE OF THE VALID FEATURES TO USE ON Which Source Files and to understandthe impacts of usding featuring. Refer to the ECMS User's Manual for

A More Detailed Discussion of Featuring, ITS USE, And ITS

Impact on software development.

Implementation Restrictions Are listed here:

Feature Lines, Including Any Continuation of the Expression,

Must Be Less Than Or Equal to 512 Characters.

THE

#feature

and

#ndfeature

Constructs Must Begin in Column 1.

The Exclusion of Source Code May Be Done with Either "Not" OR "!" In The

EXPRESSION.

For Consistency, Use Whichever Method Is Currently in The Source Code.

Use existing

#feature

Statements Rather

Than Introducing More Featuring When THE MR Adding The ORIGINAL

Featuring Construction Has Not Been Added To your target loading yet.

Reusing featuring constructs add by mrs which area not yet approved

CAN Lead to dendencies.

If you cannot Accept the dependency,

One May Add Additional Featuring Statements to Avoid Any

Mr dependencies.

THE FOLLOWING IS An Example of Featuring and The Extracted Code for

Both Feature "a" and feature "b" Versions.

Editable Version

/ * Common code. * /

a

b

c

#feature (a)

/ * Code for feature a only. * /

x

x

x

#ndfeature (a)

/ * More Common code. * /

di

e

fly

#feature (b)

/ * Code for feature b Only. * /

G

hide

i

#ndfeature (b)

/ * YET MORE Common Code. * /

j

k

l

Extracted Versions

Feature a Version Feature B Version

/ * Common code. * / / * Common code. * /

a a a

B B

c c

/ * Code for feature a only. * / / * More common code. * /

X DX E

x f

/ * More Common code. * / / * Code for feature b Only * /

D g

e h

f

/ * YET more Common code. * / / * Yet more common code. * /

J J

K K

L L

The Following Illustrate The Correct and IncorRect Methods

Of adding code 'b' for the software rectection supporting Feature C:

Bad Coding Practice:

/ * Common code * /

#feature (c)

a

#ndfeature (c)

#feature (c)

b

#ndfeature (c)

/ * More Common code * /

Good Coding Practice:

/ * Common code * /

#feature (c)

a

b

#ndfeature (c)

/ * More Common code * /

6. Coding Techniques, Style, And Format (1100.1200.10.6)

6.1 Function Definitions, Invocations, And Templates (1100.1200.10.6)

A "Function Template" Refers to a Function Declaration That Also Contains

Argument and return type information. Function Templates Are Contained in

Template Header Files That (when Included) Enable The Compiler To Verify That

Actual Function Calls agree with the Template in Type and Number of Arguments.

The purpose of this "type-checking" is to catch ceertin function interface

Faults Between Programs as Early as Possible.

Function Templating Saves The Effort of Manually Finding and Fixing

Function Interface Faults at some increased Expense in Liding Costs.

Also, Function Templating is a more automatic and reliable way of catching

Function Interface Faults Than Manual Inspection Or Testing. a cost / benefit

Analysis of function Templating Indicates That The Savings in Finding Andfixing Faults Meets or Exceeds The Increased Expense In Liding Cost

(For more details, see the cost / benefit analysis in 112000 / v1100 / 10 / 1200.t).

Function Templates Must Be Implement by All Subsystems.

All Functions Must Have A Function Template. This Coding Standard Applies

NOT Only to New Code But Also To EXISTING CODE. The Long-Term Goal IS To

Be Able To Compile with the Option That INDICES THAT A FUNCTION IS CALED

WITHOUT A TEMPLATE BEING Defined. (adding usr_cflags = "- warn, templates" to

THE MODBUILD Command Line Will Cause The Compiler To Warn of Missing Templates

For Both Defined and Reference Functions.)

Exceptions are allowed Only by consSensus within a subsystem if the templating

Causes Extraordinary Resource Demans. Exceptions by a subsystem must be flly

Document and maintained Under CMS Control in a template.g "comments"

File. this file must contain details on Differences of Naming Conventions,

Conformance for New Functionality, And Other Details of What THE Web

Must do when adding or modify or using old / new functions. this comments

File Would Be Accessible To All Developers and Would Explain Any of The Subsystem's

Templating Exceptions, Naming Variances, AS Well As Differences Between Releases

(E.G., Between u.s. and international releases).

This Templating Coding Standard Applies To All Subsystems, Promotes

CommONAlity Between The U.S. and INTERNATIONAL PRODUCTS, And Allows Flexibility.

Subsystems Must Follow Thase Standards as The Add New Code or As The Modify

EXISTING CODE. Subsystems May Grandfather EXISTING TEMPLATING Schemes; Otherwise,

The Must Use The T-File Organization Scheme Described BELOW.TEMPLATES MUST BE OF THE FORM ...

[exTern | static] return_type func (arg1_type, arg2_type, ..., argn_type);

For example:

Extern ExretVal EXFUNC (Exshort, EXLONG *);

Declares That The Function EXFUNC RETURNS A VALUE OF TYPE EXRETVAL AND

Takes Exactly Two Parameters: An Exfire.

A function template or declaration shouth be precededed by a

Linkage Specifier, Either

Extern

oral

Static

. A

Static

Linkage Specifier Can Only BE Used In a Template Header File

Of Module Scope. Any Function Template Or Declaration Without a Linkage Specifier

IS

Extern

By Default.

Functions

Must

Be defined

WITH EXPLICIT RETURN TYPES. IF A Function Does Not Return A Value, The Type

Void

Should be used. Defaulting to an an

Implicit Return Type of

int

Is not permitted.

A Function Template IS

Always

A Function

Declaration Butt Declaration is not necessarily a function template.

E.G.

Extern Void EXFUNC (VOID); <- Template and Declaration

EXTERN VOID EXFUNC (); <- Declaration ONLY

THE TEMPLATE DECLARES THAT FUNCTION EXFUNC DOES Not Return A Value

And That it expects no parameters. The

Void

In The Parameter List Must Be Used in this Instance, Otherwise the Compiler

Will See The Template As a Declaration Only And Will NOT WARN IF A Parameter

IS passed.

The use of ellipses (...) to disable the checking for arguments

Should Be Used Only In Special Cases When Necessary.

Function Templates Should Be Organized Into Template Header

Files That Have Three Logical Levels of Scope As Follows:

Global (UHDR / SS): Functions Called Outside of The Subsystem.

Subsystem (SS / HDR): Functions Called Local To The Subsystem.Module: Functions Called Local To The Module.

Functions Should Be Scoped At The Lowest Level Possible To Prevent Unnecessary

Dependencies and rebuilds.

The Scheme Described Below Is The Recommended Way To Organize

Function Templates at all scopes, and is the default scheme for globally scope

Templates. WHERE POSSIBLE, SUBSYSTEMS SHOULD IMPLEMENT A Common Function Templating

Scheme for All Releases (E.G., A CommON IMPLEMENTATION for Both the u.s. and

INTERNATIONAL PRODUCTS.

IF a subsystem HAS Already CREATED FUNCTION TEMPLATE FILES USING A DIFFERENT

Scheme, The Subsystem Can Keep The EXISTING NAMING CONVENTION AND Scheme and

Document The Scheme in The Template.g Comments File Described Above.

In any Templating Scheme, Function Templates Should Be Logical Organized

And Partitioned Into Multiple Template Header Files To Reduce The Number of

REBUILDS WHEN Program Changes Are Made.

If a subsystem has not yet create function template files, the subsystem

Should Follow The Recommended Scheme.

6.1.1 Recommended Template Organization Scheme (1100.1200.10.6)

A CommON Function Templating Organization Scheme Should Be IMPLEMENTED

For All Releases (E.g., A CommON IMPLEMENTTION WITHIN A SUBSYSTEM for Both

The u.s. and international product. To eat in Reusing code BetWeen T

U.S. and International Products, Templating Code Should Be Added with Feature

Construct Names That Are Not CBU Dependent.

A Moducts (low-level objects). It is recommented

That a subsystem's template header files be Organized so it its defined

Function Templates Are Maintain ON Either A Module OR Product Basis, Dependingon The Design of The Individual Subsystem. The Product Basis, Described

Below, Is The Most General Case, And Must Be Used WHEN A Module Builds Products

That Use The Same Function Name Defined Differently Across these Products.

For Many Subsystems That Do Not Have this Situation, Using The Module Basis

To Organize Their Templates Is Sufficient and Will Reduce The Number of Template

Header Files That Must Be Maintained. in The Descriptions Below, Substitution

Module

for

PRODUCT

and

MOD

for

PROD

TO Get The Module Basis Scheme.

Each Low-Level Product Must Maintain Template Header Files

Containing The Templates for All Functions Defined in That Product. EACH

Product Will Have At Most Three Template Header Files Depending Upon The Scope

Of where the functions are called. The Product's Template Header Files Should

Be Organized and named As Follows:

UHDR / / T .g Global Scope Templates

/ hdr / t .l subsystem scope templates

/ / t .h module scope templates

Using the naming convention above, if Functions Are Built In To More

Than A Single Product, THESE FUNCTIONS MUSTAIN More Than One Template,

I. One per produter.

The Templates Should Be Enclosed in

#if ... #endif

STATEments to Separate Templates

That Differ Across Different Selector Combinations, And to Make Maintenance

Of Identical Templates Across Selectors Easier. If A Function is Scoped Differently

For Different Selectors, E.G. Subsystem for Pam and Global for PSM, Maintain

The Template Using The Higher (I.E. Global) Scope.

.

The Order of Header Files Will Help in Locating Extra INAPPRIATE

Function Declarations. if a subsystem HAS ALREADY INCLUDED TEMPLATE HEADER

Files in Their Module Declaration Files, The Subsystem Can Keep THEIR EXISTING

ORDERING.

For The Product Exprod in Module Exmod, The Header Files in The

Uses

List shop be maintained in this Order:

Uses =

/TEXPROD.H / * GLOBAL Scope Functions Defined * /

/ * in exprod, if any * /

TEXPROD.H / * SUBSYSTEM Scope Functions Defined * /

/ * in exprod, if any * /

... / * Other Global and Subsystem Scpe * /

... / * Template Header Files for * /

... / * functions reasond by exprod * /

... / * All Non-Template Global and * /

... / * Subsystem Header Files * /

;

The Header Files in The HEA

HEADER

List shop be maintained in this Order:

HEADER =

... / * All Non-Template Module Header Files * /

TEXPROD.H / * MODULE Scope Functions Defined in * /

/ * EXPROD, IF ANY * /

... / * Other Module Scope Template Headers * /

... / * for functions caled by exprod (i.e. * /

... / * functions defined in another esmod * /

/ * Product), if any * /

;

All Data Types Reference by Function Templates Must Be Available

At The Proper Scope. Global and Subsystem Scope Template Headers Must Contain

The appropriate

#include

Directives for

Any Data Types Reference In The Templates. for module scope template headers,

Reference Data Types Must Be Made Visible To The Template Via Theheader

oral

Uses

List in the module decaration

File. Any Reference Data Types Declared in Source Files Must Be Moved Into

A header file.

IF a macro exissrs in a non-template header file for the purpose

Of Hiding The Actual Function Being Called, The Function Template Should

Precede the macro definition in The Non-Template Header File. this is an

Exception to the Above Templating Organization Scheme.

For Scoping Purposes, Fat Table Entry References To a Function

Can Be ignored. Also, Fat

Table Entries Do Not Have to Reference

Function Templates; They May Continue To Use Function Declarations. this

Is Because The Use of Osfap () TO Invoke A Function Forfeits the Capability

TO Perform type-checking.

Function Invocations Must Match Function Definitions and Templates

In Number and Type of Parameters. In Other Words, The Arguments Passed To

A Function Must Agree In Number and Type with the arguments defined for That

Function. The Exception To this rule is functions That Have Templates That

Allow for a variable number of parameters may use elipses (...). for esample,

A Function That Requires At Least One Parameter, AN Exshort, But May Have

More Parameters Would Have A Template of The Form:

Extern ExretVal EXFUNC (Exshort, ...);

When Passing

Struct

oral

union

Pointers as parameters, do not

Define the body of the

Struct

oral

union

In The Function Definition Parameter List.

Always use previously defined

Struct

oral

union

Types So That a Function Template

Can Be provided. for example,

Bad Coding Practice:

Exretval

EXMSGFUNC (MSG_PTR)

Struct {

EXMSGHEAD MSGHEAD;

Exmsgtext text;

} * msg_ptr;

{

...

}

Good Coding Practice:

Typedef struct exmessage {exmsghead msghead;

Exmsgtext text;

} Exmessage;

/ * Good practice in source file * /

Exretval

EXMSGFUNC (MSG_PTR)

Exmessage * msg_ptr;

{

...

}

6.2 Data Definitions and Declarations (1100.1200.10.6)

Function Declarations and Data Declarations with global scope

(Across Source Files) Must Be supplied and

Extern

Edin Global, Local, or Module Header Files Provided by the Referenced

Subsystems. Use a Module Header File for Scope Withnin A Module, A Local HEADER

File for Scope Withnin A Subsystem, And A Global Header File for Scope Crossing

Subsystem Boundaries.

When Using

Unions

for

OSDS Messages, Ensure the Union Contains Only Those Messages Which Are Expected

(or a large majority of them). if The Union Contains Many Other Unnecessary

Merses, Consider Creating Another Union Containing Only the Required Messages.

Avoid Declaring Message Unions WITHIN A Function. THIS CAN LEAD to NUMEROUS

Function Changes When Adding New Expected Messages.

Choose Integral Data Types According to the Following Criteria:

IF The Quantity Must Be of A Fixed Size (in An Inter-Processor

Message, for example, use a type tres to a

charr

,

Short

OR a

Long

As Required.

OtherWise, IF The Quantity May Exceed 16 Bits, Use a Type

That Resolves TO A

Long

.

Otherwise, IF The Quantity Has Storage Class

Auto

And Space Efficiency Is More Important Time Efficiency,

Use a Type That Resolves TO A

charr

oral

a

Short

.

Otherwise, Use a type tria resolves to an an

int

.

Initialization of Non-Constant Non-Static Local Variables

Must Be done in the code segment rather Than at the point of definition.

It is recommended That Only One Variable or Function Be Declared

Per Line. this Enhances Readability, Provides the Opportunity for Bettercomment, and Makes Maintenance Easier if some variables or functions change

Type. this is a recommendation rather Than a rule because it make ocquasionally

Make Sense To Group Closely Related Variables That Act As Part of Larger Conceptual

For example:

Exshort Currow, Curcol; / * Current Screen Position * /

When Declarations Are Not One-Per-Line, The Following Rules Apply.

Don't Mix Variables and Functions With Same Declaration.

Don't Mix Initialized and Uninitialized Variables within the

Same Declaration.

6.3 Type Conversion (1100.1200.10.6)

The Following Integral Promotions is Performed:

Operands of Type

charr

oral

Short

Are Converted to Type

int

Promotion of

charr

TO

int

May Involve Zero-Padding

OR SIGN EXTENSION, Depending on The Compiler. Promotion of

Short

TO

int

Is Always Done

WITH SIGN EXTENSION.

Operands of Type

Unsigned char

May Be Converted to Type

int

oral

Unsigned int

Depending on the compiler.

Operands of Type

Unsigned short

Are Converted to Type

Unsigned int

.

Bit Fields Are PROMOTED TO Either Signed Or Unsigned Quantities,

Depending on the compiler and the size of the bit field.

Given Two Operands with Promoted Types As Shown In The Left Column and

Top Row Below, The Operands Undergo Arithmetic Conversion To The Type Shown

In The Table, And The Result of The Operation Will Have The Same Type (See

Section 6 of Reference [P]):

With The Exception of The Values ​​Null and 0, Use Type Casts for ALL

Conversions Not listed Above Or That Are listed as being compiler depend.

The Values ​​Null and 0 Need Not Being Pass Unless They Are Being Pass

as function call parameters.table 6.-2. Arithmetic Conversions

int

Long

Uint

Ulong

int

int

Long

Uint

Ulong

Long

Long

Long

[u] long

Ulong

Uint

Uint

[u] long

Uint

Ulong

Ulong

Ulong

Ulong

Ulong

Ulong

WHERE uint Stands for

Unsigned int

And Ulong Stands for

Unsigned long

.

THE [U] Long Entries May Be Either

Long

oral

Unsigned long

Depending on the compiler.

Integral Types Undergo Arithmetic or Storage Conversion As Follows:

If the Source And Destination Are The Same Size, The Bit Pattern

IS unchanged.

A Source IS Converted to a Smaller Destination by Truncating

The High-Order Bits.

An Unsigned Source Is Converted to a Larger Destination By

ZERO-PADDING.

A Signed Source IS Converted to a Larger Signed Destination

By SIGN EXTENSION.

A Signed Source IS Converted to a Larger Unsigned Destination

By Zero-Padding or Sign Extension, Depending on The Compiler.

6.4 Variables and constants (1100.1200.10.6)

Variables May Not Be Used for more Than One Purpose within

Their Scopes, Except When Used Only As Loop Counters, Array Indices Or Return

VALUES.

Register Variables Can Be Freely Used to Obtain Real-Time

Efficiency. However, They Cause A Minor Problem in Debugging 3B20 Programs

Using Dart Because Only The Register Variables in The Currently Active Function

Can Be Displayed. The Restriction Does Not Apply to Debugging MC68000 Program

Using ITS Because The MC68000 Stack Design Is Different from That of the 3b20.

Consideration Should Be Given to The Fact That Register Variables Less

Than Four Bytes Will Increase Stack Space. This is Because Registers Used

For Variables Are Saved on The Stack At Function Entry. for Example, IF A

TWO-byte variable is registerized, two bytes will be wasted on the stack.for mc68000, Stack overflow Must Be Considered When Registerizing Variables.

See Reference [q].

THE

Called

Function is responsole

For The Saving and Restoring of All Registers. so The stack space Used for

Registers Does Not Dend On WHETHER A FUNCTION CALLS Another Function. IT

Will always be used.

Some Compilers Will Automatically Registerize Variables based on usage.

Definitions of Automatic Variables SHOULD BE Ordeering by size

And Type Take Advantage Of Addressing Alignment Characteristics. Exceptions

May Be Necessary for Asserts, Which Dump Only The First 180 Bytes of the Stack

Frame.

Constants That Have a Specific Meaning (E.G., Number of Line

Units, Maximum Buffer Size, Number of Array Elements, etc.) Must Be Given

A descriptive

#define

Name. The Exceptions

To this rule area when the number 0 is buy to reference the first item in

An Array, And The Use of 0 OR 1 As The Initial Or Final Value of a Counter.

The Method of Initialization of Constants Depends on The Type

Of constant to be initialized. The Following Types of Constants Are Distinguished:

#define

Constants: True

Constants Which Are Defined Using

#define

.

Local Constants: Local Variables Whose Values ​​Remain Constant

During the execution of their enclosing functions.

Global Constants: Global Variables Whose Values ​​Remain Constant

For a particular load or installation.

Local and global constants must be initialized at their definitions.

All Variables Must Be Initialized Before Uses.

6.5 Stack USAGE (1100.1200.10.6)

Various techniques can be used to minimize stack usage in order to prevent

Stack Overflow Problems. Here Are Few Examples Which Can Help Minimize Stackusage.

Declare All Local Variables from Largest to Smallst in size.

Therefore, All Structures Should Be Decland First, Followed by Longs, Pointers,

INTEGERS, SHORTS, AND THEN CHARACTERS OR Booleans, In That Order. this Will

Compact The local declarations as much as possible on the stack.

INSTEAD of DECLARING LARGE STRUCTURES in Very High Level Functions

(Functions at the top of the stack), Declare Structures in .bss data if possible.

When this Is Done, Care Must Be Used to Ensure That The Data Will Not Be Corrupted

IF A Real Time Break Is Taken. The .bss Data Does NOT OCCUPY ANY Stack Space

And Can Be Reference Much Like Global Parameters.

USE UNIONS INSTEAD OF DECLARING MANY DIFFERENT STRUCTURES

On The Stack. This Is Especially Useful for Relation Structures Being Placed

On The Stack Which Are ONLY Used ONCE IN ORDER TO OBTAIN DATA TO Read Other

RELATION LATER. for esample:

Union {

Struct rlbigrel1 rel1;

Struct rlbigrel2 rel2;

ALL_RELS;

/ * Some code Here. Initialize Key to relation. * /

Ret = dbfrdtup (rlbigrel1, (char *) & (all_rels.rel1));

IF (RET! = Glsuccess) {

/ * Error Handling. * /

Return;

}

/ * Some more code POSSIBLY. * /

All_rels.rel2.key = all_rels.rel1.store;

Ret = dbfrdtup (rlbigrel2, (char *) & (all_rels.rel2);

IF (RET! = Glsuccess) {

/ * Error Handling. * /

Return;

}

In The Above Example, It May Be Necessary To Temporarily Store The VALUES

Retrieved from The First Read Into Local Variables So That They Are Not Overwritten

When the information is copied in osits t in t t the second

The use is necessary, The Amount of Stackspace Required To Store Temporary Variables Which Are Needed in The Subsequent

Reads Is Likey Less Than The Amount of Space Needed to Declare The Entire

RELATION on the stack.

Another Alternative, Similar To The Idea Above, IS To Add

Extra Function Calls. In General, a Function Call Will Add to the Stack Space.

However, Smart Use of Additional Functions CAN Actually Decrease Stack Space.

A Function Which Has Many Declarations on Its Local Stack Can Be Modified

TO Call Two or More Functions Which AccompLish THE Same Functionality As The Same

Large Function, But Each Only Containing A Subset of The Local Declarations.

This Has The Benefit of Moving Many of the Local Declarations To Lower Level

Functions Which Will Be Popped Off The Stack When The isy. Therefore,

Having One Large Function with Many Local Declarations Can Use More Stack

Space Than Group of Functions Called By A Higher Level Function Which USE

A Small Portion of the Large Function's Declarations.

Declare variables as locally as possible. Instead of declaring

All the local variables at the beginning of the function, Declare Some within

Case Statements and if Statements. The Compiler Optimizes this Stack USAge,

Treating these Similar to Unions. Below Are Two Examples of Such Stack Usage:

EXAMPLE 1:

Switch (value) {

Case Value1:

{

Struct rlbigrel1 rel1;

/ * Use Bigrel1 * /

}

Break;

Case Value2:

{

Struct rlbigrel2 rel2;

/ * Use bigrel2 * /

}

Break;

DEFAULT:

{

Struct rlbigrel3 rel3;

/ * Use bigrel3 * /

}

Break;

}

EXAMPLE 2:

IF (value == 0) {

Struct rlbigrel1 rel1;

/ * Use Bigrel1 * /

} else {

Struct rlbigrel2 rel2;

/ * Use bigrel2 * /

}

6.6 Operand Grouping (1100.1200.10.6)

The Following Table Lists C Operator Associative and Precedency in

Decreasing Order by Row:

Table 6.-3. Operator Precedence, Associative, And Type

Type

Operator (s)

Associative

primary

() [] ->.

LEFT TO RIGHT

Unary

! ~ - - (TYPE) * & Sizeof

Right to Left

MultiPlicative

* /%

LEFT TO RIGHT

Additive

-

LEFT TO RIGHT

Shift

<< >>

LEFT TO RIGHT

RELATIONAL

<=>> =

LEFT TO RIGHT

Equality

==! =

LEFT TO RIGHT

Bitwise

&

LEFT TO RIGHT

Bitwise

^

LEFT TO RIGHT

Bitwise

|

LEFT TO RIGHT

Logical

&&&&

LEFT TO RIGHT

Logical

||

LEFT TO RIGHT

Conditional

?:

Right to Left

Assignment

= = - = ETC.

Right to Left

Comma

,

LEFT TO RIGHT

The Relative Precedency of The Primary, Unary, Multiplicative, And Additive

Operators Is Fairly Well Known, As Is The Relative Precedence of The Relational

And Equality Operators to the logical Operators. Knowledge of other precedences

Varies Quite a Bit from Person to Person and Should Thereree Be Made Clear

THROUGH The use of perentheses. Use of perentheses to indeicate the intended

Operator Associative '-' Operators and Factors

Involving multiple '/' or '%' Operators is Recommended. Uses Use Conservative Judgement

When Eliminating Redundant Parentheses To Increase The Readability Of Extremely

Complex Expressions. for example:

Bad Coding Practice:

(((A B) C) D) / * inteention is clear; () s Just Add Clutter * /

A B / C >> EXCONST / * Precedence Is Not ALWAYS Remembed * /

A> b == c> D / * DITTO * / / *

* Elimination of White Space to Indicate Precedence May Be

* misleading. The Following Appears to Suggest

* precedence of "/" over "*". White Space Must Not Be Used

* to suggest precedence.

* /

A * B / C - D

/ * This is equivalent to (x & (exxmsk == 0)) && (Y & (exYmsk! = 0)) * /

X & exxmsk == 0 && y & examplek! = 0

/ * This is equivalent to (attrib & extall) | EXWIDE * /

Attrib & Extall | EXWIDE

Good Coding Practice:

A B C D / * INTENTION IS CLEAR for () S * /

/ *

* "/" HAS Higher Precedence Than " " by Mathematical Standard;

* () s show precedence of " " and "/" over ">>"

* /

(A B / C) >> EXCONST

(a> b) == (c> d) / * () s clarify precedence * /

/ *

* () s show left to right associativity of equal-precedence "*" and "/";

* "*" AND "/" have higher precatednce "-" by Mathematical Standard

* /

(a * b) / c - d

/ *

* Both of The Following Styles Are IN Common Use. The First Leaves NO

* Questions about precedence; the second signally reduces code clutter.

* /

(X & Exxmsk) == 0) && ((Y & Exymsk) == 0)

(x & exxmsk) == 0 && (Y & Exymsk) == 0

More Information About Operator Precedence Can Be Found In Section 2.12

of Reference [a].

6.7 #includes (1100.1200.10.6)

All Subsystem-local and global header files must

#include

Any Header Files Needed to Define Symbols

Used in The Header File

[1]

.

In The ModuLarity Environment, NO Module-local Header Files (I.e. Header Files Which End With OR .LH)

OR Source Files May Contain

#include

Statements. Any Header Files That Sests Require Should Be Included in

The Module Declarative File.

1.

In the pre-modularity environment,

Header Files Began with a

#define

WITH

a unique name. Inclusion of Each Header File in Other Files Was Conditional

On The Unique Name to Prevent Multiple Inclusion. This Technique Should No

LONGER BE PRACTICED AS CURRENT Header File Processing Makes this Unnecessary.

6.8 Preprocessor Conditionals (1100.1200.10.6)

Conditional PreProcessing (Using

#if

,

#ifdef

,

#ifndef

,

#elif

,

#ELSE

, and

#ENDIF

SHOULD

BE Used with Great Care Since The CLUTTER THE Natural Flow of the Code. The Code..

FOLLOWING Are Restrictions / Suggestions on Their USE:

Conditionals Should Only Be Used for Minor Differences Based

On The Definition of a Flag. Major Difference Should Be Handled by Providing

Separate functions.

Conditional Changes Withnin A Function SHOULD BE LOCALIZED

As Much As Possible and Not Scattered THROUGHOUT The Function. That IS, Any

Decisions That Depend Upon The Conditional Expression SHOULD BE MADE INE

Place if Possible.

A Conditional Must Not Split or Interrupt The Flow of a Complete

C Statement. For example:

Bad Coding Practice:

IF ()

#ifdef bar

|| ()

#ENDIF

) {

/ * Do Some Stuff * /

}

Good Coding Practice:

#ifdef bar

IF ()

#ELSE

IF ( || )

#ENDIF

{

/ * Do Some Stuff * /

}

This Approach Results in Increased Readability and Maintainability of

Code. Do Not Sacrifice Clarity of Code to Save Typing Or Tiny Amounts OFMEMORY.

6.9 Macros (1100.1200.10.6)

Macro Definition Syntax Rules:

IF a Macro Definition Contains Several C Statements, Therements

Must Be Put on Separate, Back-Slash Terminated Lines Enclosed by a

Do-while (0)

For example:

Bad Coding Practice:

#define exmacro () ; ;

Good Coding Practice:

#define exmacro () /

DO /

{/

; /

; /

; /

} /

/ * Constantcondition * / /

While (0)

THE

Do while (0)

Causes the macro

To Expand to a Single, Simple Statement Terminated by Exactly One Semicolon

(Provided by the Invoker). This Format Prevents Problems with

IF-Less Else

(Caused by Two or More SEMICOLONS WHEN A Macro IS

Expanded) and

Else-Less IF

(See the First

EXAMPLE IN THIS INVOKED AS A Simple-Statement

Body for ann

IF-Else

Statement.

THE

/ * Constantcondition * /

Prevents

Lint Errors Due To The Fact That The Condition With WHILELOP IS A

Constant Expression, Always Resulting in a false Indication. This String Must

Not be omitted. if not buy, a Lint Error Will Be Generated, One for Each

INVOCATION OF THE MACRO.

Arguments to a Macro That Can Be C Expressions Must Be Preenthesized

THROUGHOUT The Macro Definition. In Addition, Any Macro whose results is a

C Expression Must Be Parenthesized in Its EntireTy IT Contains An Operator

And is not of the form

Sizeof

(

Expr

). For example:

Bad Coding Practice:

#define eXCONST EXOTHER_CONST 1

#define exmax (x, y) x> y? x: y

Good Coding Practice:

#define eXCONST (exother_const 1)

#define Exmax (x, y) ((x)> (y)) The Preentheses Are Necessary TO Ensure That The Intended Operator Precedence

Holds Regardless of How The Macro IS Used, And Regardless of the Nature Of

Expressions passed as arguments.

Macro Readability and Maintainability Rules:

Macro Nesting and Size Should Result In Maintainable Software.

Very Large Macros and Macros That Call Other Macros THROUGH MANY Levels of

Nesting Can Cause MaintainAbility Problems and Excessive Memory Usage. Excessively

Nested Macros Can Make Code Less Readable and More Diffult To Maintain and

Debug. minimize the levels of nesting and macro size to avoid these problems.

IF a macro is large, consider making it Into a function.

Macros Should Only Be Used to Make Code Easier To Read and / OR

More flexible (When the extra flexibility is needed).

In this example, Either of these Two definitions of a macro to increment

A Variable Using MODULO ARITIC Might Be Used, Depending ON Efficiency

Considances:

/ * increment x modulo m assuming 0 <= x

#define exincmod (x, m) ((x) = ((x) 1)% (m))

oral

/ * increment x modulo m assuming 0 <= x

#define evincmod (x, m) /

DO /

{/

IF ( (x) == (m)) /

(x) = 0; /

} /

/ * Constantcondition * / /

While (0)

Both of these Definitions Perform The Desired Operation, But The IMplementation

Details and The Fact That One is an expression and the other is not is hidden.

This next example showing to hide a minor, though

Obscuring, Detail, Such As Embedded Structure Names:

X_PTR-> name1.name2.name3.name4.name5.key = 0;

Can Be More Clearly Written:

#define evItem_key name1.name2.name3.name4.name5.keyx_ptr-> exiteM_key = 0;

Macros Should Definitely

NOT

Hide Important Details,

Significant Operations or Side Effects (especially changes in flow control).

Consider Using Self-Description Names for Parameters in Function-Like

Macros to make Complex Macros Or Macros with Many Parameters Easier To Understand.

6.10 Comments (1100.1200.10.6)

Comments shop be added to source code to aid in the understanding

Of the program or to provide a ready with any sales

To Understand The Code. Misleading Comments Are Worse Than No Comments. Uses

. The Following Rules.

There Are Three Acceptable Comment Styles: Trailing Comments,

Single-Line Comments, And Block Comments.

Trailing Comments Are Short Comments That Appear At the end

Of a line of code and describe That Single Line of Code. The text of the

Comment shop be sepaper.com The '/ *' and '* /' delimiters by White Space.

Trailing Comments Withnin A Block of Code Should Be Tabbed to Line Up with

Each other. for example:

Int argc; / * argument count * /

Char * argv []; / * argument list * /

IF a comment is too long to fit on the line it it describes, use the salesle-line

Or block "Comment format.

SINGLE-LINE Comments SHOULD BE Used for Comments That Describe

A Single Line But Are Too Long To Fit As a Trailing Comment Or for Comments

That Describe Multiple Lines But Will Fit On ONE.

A Single-Line Comment Precedes The Code It Describes, and Should Be

Indented to match the code. like trailing commerss, the text of single-line

Comments shop be self-owned from the '/ *' and '* /' delimiters by White Space.

For Example: / * Sort Temp Unique on The Second and Third Fields. * /

Execl (Exec, Exsort, "-u", " 1", "-3", temp, "-o", temp, (char *) NULL);

See T

NLINT

(1) MANUAL Page for a list of special

SINGLE-LINE Comments Used to Modify The Behavior of NLINT.

Block Comments Should Be Used for Any Comment That Will Not NOT

Fit on one line. Do Not Stack Single-Line Comments. Visually, A Block Comment

Looks like this:

/ *

* This is a block comment. Note That the

* Delimiters Are ON Lines by Themselves.

* /