rmcgb__cel_mai_util.pdf

ATTOL UniTestReference ManualC Language

http://www.attol.com

Reference Manual - C Language 1

Copyright 1992-2000 ATTOL Testware SA. All rights reserved.

Version 3.4 - February 29th, 2000

Information in this document is subject to change without notice and does not represent a commitmenton the part of ATTOL Testware SA. The software described in this document is furnished under alicense agreement. The software may be used only in accordance with the terms of that licenseagreement. It is against the law to copy or use the software except as specifically allowed in thelicense.

ATTOL, ATTOL UniTest, ATTOL Coverage, ATTOL SystemTest, and the ATTOL logo are eitherregistered trademarks or trademarks of ATTOL Testware SA in France and/or other countries. Allother names are used for identification purposes only and are trademarks or registered trademarks oftheir respective companies.

Visit our Web site: http://www.attol.com

Reference manual C Language page 2

TABLE OF CONTENTS

1. INTRODUCTION 4

2. THE ATTOL LANGUAGE 5

2.1. Syntax 52.1.1. Lexical Elements 52.1.2. Syntax summary 6

2.2. Instructions 9

2.3. French VERSION 44

3. THE C ANALYZER 45

3.1. The C preprocessor 453.1.1. Grammar of the C preprocessor 453.1.2. Predefined constants 463.1.3. ATTOL pragmas 46

3.2. Grammar of the C analyzer 47

3.3. C Expressions 50

3.4. Lexical elements 513.4.1. Identifiers 513.4.2. Constants 523.4.3. Character strings 53

4. THE ATTOL TEST GENERATOR 54

4.1. Command 54

4.2. French Version 89

4.3. Return Code 90


5. THE ATTOL REPORT GENERATOR 91

5.1. Command 91

5.2. Changing default extensions 103


5.4. Return Code 105

6. THE ATTOL TEST PLAN GENERATOR 106

6.1. Command 106


6.3. Return Code 115

7. ATTOL RUNTIME 116

8. GLOSSARY 120

9. ATTOL ERROR MESSAGES 121

9.1. Information messages 122

9.2. Warning messages 125

9.3. Errors 140

9.4. Fatal errors 146

10. INDEX 150

ATTOL UniTest Introduction


1. INTRODUCTION

This manual is the ATTOL Reference Manual - C language. It is recommended that you read the ATTOLProgrammers Guide - C language before reading this manual.

This manual describes the following items in the form of reference sheets :

9 ATTOL language instructions,

9 directives analyzed by the ATTOL C preprocessor, and the syntax of the C analyzer,

9 parameters and options for the ATTOL Test Generator,

9 parameters and options for the ATTOL Report Generator,

9 ROD file library entry points,

9 parameters and options for the ATTOL test plan generator,

9 ATTOL runtime entry points,

9 ATTOL error messages.

This manual is aimed at users of ATTOL.

It describes the syntax of languages recognized by ATTOL. In order to do this, it uses BNF script. This scriptrespects the following rules :

Syntax : [] : optional (0 or 1 instance){} : from 0 to n instances| : or : itemMO : keyword() : comment

ATTOL UniTest The ATTOL language


2. THE ATTOL LANGUAGE

2.1. SYNTAX

2.1.1. Lexical Elements

The ATTOL language is composed of a series of instructions into which C code can be inserted. ATTOLinstructions and C Code follow the following rules :

9 each instruction begins with a keyword and ends at the end of the line,

9 the ampersand character ('&') can be used at the beginning of the line to extend an ATTOL instruction ontothe next line,

9 the length of an instruction is limited to 2000 characters,

9 C code included in the instructions begins with # or @.

ATTOL language instructions begin with the following keywords :

ARRAY,BEGIN,COMMENT, CONST,DEFINE,ELEMENT, ELSE, ELSE_SIMUL, END, ENVIRONMENT,FAMILY, FORMAT,IF, INCLUDE, INITIALISATION,NEXT_TEST,SERVICE, SERVICE_TYPE, SIMUL, STR, STUBTERMINATION, TEST,USE,VAR



Furthermore, the following keywords can be found in the body of the instructions :

BOUNDS,CODE,DELTA,EV,FROM,IF, IN, INIT,LOOP,MAX, MIN,NB_RANDOM, NB_TIMES,PTU,SIMUL, STEP, STUB,TO,WITH

These keywords may be written in upper or lower case in any ATTOL instruction.

2.1.2. Syntax summary

test_plan ::= header BEGIN { decl_before_service } { services }header ::= HEADER module_name , module_ver , test_plan_ver

module_name ::= string

module_ver ::= string

test_plan_ver ::= string

decl_before_service ::= constant |environment |use |comment |format |stub_definition |initialisation |termination

constant ::= CONST constant_name = value

constant_name ::= identifier

value ::= string

environment ::= ENVIRONMENT environment_name [ ( param { , param } ) ]attol_tests END ENVIRONMENT

environment_name ::= identifier



param ::= identifier

attol_test ::= attol_test { attol_test }use ::= USE environment [ ( param_value { , param_value } ) ]param_value ::= string

comment ::= COMMENT string

format ::= FORMAT type_or_variable = C_type

type_or_variable ::= C_type |C_variable |structure_name . field_name

stub_definition ::= DEFINE STUB stub_name [ stub_dim ] { def_of_stub } ENDDEFINE

stub_dim ::= number

def_of_stub ::= # C_variable_decl ; |# stub_function

stub_function ::= [C_ type ] name_of_stub ( parameter { , parameter } ) ; |[ C_type ] name_of_stub ( ) ; |[ C_type ] name_of_stub ( void ) ;

name_of_stub ::= identifier

parameter ::= C_type [ pass_mode ] parameter_namepass_mode ::= _in |

_out |_inout |_no

parameter_name ::= identifier

initialisation ::= INITIALISATION C_code END INITIALISATION

termination ::= TERMINATION C_code END TERMINATION

services ::= service { service }service ::= { decl_outs_service } SERVICE tests END SERVICEdecl_outs_service ::= environment |

use |comment |format |stub_definition |initialisation |termination

tests ::= test { test }



test ::= { declarations } TEST string [ LOOP number ] family elements{ NEXT_TEST string [ LOOP number ] elements } END TEST

declarations ::= environment |use |comment |format

family ::= FAMILY string {, string }elements := element { element }element ::= { declarations } ELEMENT phase END ELEMENTphase ::= phase_elem { phase_elem }phase_elem ::= environment |

use |comment |format |attol_test

attol_test ::= mode C_variable , init , ev |stub

mode ::= VAR |ARRAY |STR

init ::= INIT = C_exp |INIT == |INIT IN C_expression_list |INIT ( variable_C ) WITH C_expression_list |INIT FROM C_exp TO C_exp STEP C_exp |INIT FROM C_exp TO C_exp NB_TIMES number |INIT FROM C_exp TO C_exp NB_RANDOM number[ + BOUNDS ]

ev ::= EV = C_exp |EV == |EV IN C_expression_list |EV ( variable_C ) IN C_expression_list |MIN = C_exp , MAX = C_exp |EV = C_exp , DELTA = C_exp [ % ] |EV => identifier

C_expression_list ::= { C_exp { , C_exp } } |[ C_exp { , C_exp } ]

stub ::= STUB stub_name stub_call { , stub_call }stub_call ::= [ call_range => ] ( param_val { , param_val } ) [ param_val ] |

[ call_range => ] ( ) [ param_val ]call_range ::= number |



number..number |others

param_val ::= C_exp

string : any character string,identifier : character string beginning with a letter and containing only

letters, numbers, dollar signs ($) or underlines (_).number : integer expression that can be reduced by ATTOLC_type : type declared in C,C_variable : variable with a name respecting C syntaxC_variable_decl : declaration of a C variable respecting C syntax,C_exp : expressing respecting C syntax (without assignment operators)C_code: : code written in C.

Furthermore, you can introduce the following anywhere in the test plan :

x Comments. A comment begins with two dashes ("--") and ends at the end of the line (just like commentsin Ada),x Conditional generation instructions IF / ELSE / END IF and SIMUL / ELSE_SIMUL / END SIMUL

enclosing any C or ATTOL code.

2.2. INSTRUCTIONS

This section describes each ATTOL language instruction, giving the following details :

9 its syntax,

9 its functionality and rules governing its usage,

9 examples of use.



COMMENT

Syntax COMMENT comment

Description The COMMENT instruction allows you to add comments to the test report, by inserting thetext comment.

Its use in the test plan is optional; the parameter comment is also optional in this instruction.

The position of the COMMENT instruction in the test program defines the position inwhich the comments appear in the test report.

9 if COMMENT is located in an ELEMENT block, the comments appear just before thedescription of the state of the variable.

9 if COMMENT is located after the TEST instruction, the comments appear in the testheader, before the description of the variables,

9 if COMMENT is located after the SERVICE instruction, the comments appear in theservice header, before the description of the tests.

9 if COMMENT is located outside the SERVICE block, the comments appear in theservice header following the declaration, before the description of the tests.

Associated rules The COMMENT instruction can be used anywhere in the test program.

Comment can be any text.

Example TEST 1FAMILY nominal

COMMENT histogram calculation for a black image

ELEMENT



CONST

Syntax CONST constant_name = value

Description The CONST instruction defines a constant that is specific to the test plan, and that can beused thereafter in ATTOL instructions.

This instruction is optional.

Associated rules The CONST instruction must be located between the BEGIN instruction and the firstSERVICE block.

constant_name is a name of an identifier which conforms to C rules. It is obligatory.

value is a literal constant which conforms to C rules or a list of literal constants separated bycommas (',') and contained within brackets ('[' and ']') or braces ('{' and '}'). It is obligatory.

This instruction is equivalent to the following line in C :

##define constant_name value

Example BEGIN ...

CONST k = 2 CONST PI = 3.14159 CONST ch = "Hello !" CONST ST_NULL = {NIL,0,""} ...

SERVICE cercle



BEGIN

Syntax BEGIN

Description The BEGIN instruction marks the beginning of the test program.

C code generation starts after this instruction.

Associated rules The BEGIN instruction is obligatory. It must be located before any other ATTOL languageinstruction, with the exception of the HEADER instruction..

If this instruction is absent, a warning message is generated and a BEGIN instruction isimplicitly created at the appearance of the first SERVICE instruction.



DEFINE STUB / END DEFINE

Syntax DEFINE STUB stub_name [ stub_dim ]END DEFINE

Description The DEFINE STUB and END DEFINE instructions delimit a simulation block whichconsists of stub definitions in the form of C declarations (beginning with #') of :

x global variables,

x functions.

Any global variables defined in this way replace the real global variables. Definitions offunctions must be in the form of ANSI prototypes.

Stub parameters describe both the type of item used by the calling function and the mode ofpassing. The mode of passing is specified by adding the following in front of the name of theparameter :

x _in for input parameters,

x _out for output parameters,

x _inout for input/output parameters,

x _no for parameters that you do not wish to test.

A return parameter is always deemed to be an output parameter.

Associated rules Defining stubs in a test plan is optional.

stub_name is the name of a simulation block; it is obligatory.

stub_dim is the maximum number of stub call descriptions for a test scenario. This parameteris optional. Its default value is 10.

DEFINE STUB / END DEFINE blocks must be located after the BEGIN instruction andoutside any SERVICE block.

Simulated variables and functions must conform to ANSI C standards. The mode of passing



is optional. Its default value is _in.

Using the stub definitions, ATTOL generates simulation variables and functions whoseinterface is identical to that of the real variables and functions. The purpose of thesesimulation variables and functions is to :

9 store the input parameters in order to test them,

9 assign values to the output parameters and, where appropriate, to the return value.

Example BEGIN

DEFINE STUB fic #int open_file(char _in f[100]); #int create_file(char _in f[100]); #int read_file(int _in fd, char _out l[100]); #int write_file(int fd, char _in l[100]); #int close_file(int fd);END DEFINE

See also STUB



ELEMENT / END ELEMENT

Syntax ELEMENTEND ELEMENT

Description The ELEMENT / END ELEMENT instructions delimit a test phase (ELEMENT block).

This block contains in particular a C call to the service under test, and instructions describingthe initializations of and checks on test variables.

It does not matter where you position the VAR, ARRAY, STR or STUB instructions withrespect to the test procedure call since the C code generator separates these instructions intotwo parts :

x The test initialiser (described by INIT) is generated with the ELEMENT instructionx The test of the expected value (described by EV) is generated with the END

ELEMENT instruction.

The following diagram illustrates how C code is generated :

ELEMENT

END ELEMENT

VAR ... , INIT = ... , EV = ...

VAR ... , INIT = ... , EV = ...

Associated rules The ELEMENT instruction can only appear in a TEST block. It is obligatory; if absent, awarning message is generated and it is implicitly declared at the first VAR, ARRAY, STR orSTUB instruction.

The block must end with the instruction END ELEMENT; if absent, a warning message isgenerated and it is implicitly declared at the next ELEMENT instruction or at the ENDTEST instruction.



Example TEST 1 FAMILY nominal

ELEMENT

VAR x1, init = 0, ev = init VAR x2, init = SIZE_IMAGE-1, ev = init VAR y1, init = 0, ev = init VAR y2, init = SIZE_IMAGE-1, ev = init ARRAY image, init = 0, ev = init VAR histo[0], init = 0, ev = SIZE_IMAGE*SIZE_IMAGE ARRAY histo[1..SIZE_HISTO-1], init = 0, ev = 0 VAR status, init ==, ev = 0 #status = calcul_histo(x1,y1,x2,y2,histo);

END ELEMENT

END TEST



HEADER

Syntax HEADER module_name, module_version, test_plan_version

Description The HEADER instruction specifies the name and version of the module under test and theversion number of the test plan.

This information is reproduced in the test report header so that the test sequence executedcan be identified.

Associated rules The module and test plan versions can be read from the environment variables if they areidentifiers beginning with a dollar sign ($).

The three parameters of the HEADER instruction are character strings with no particularconstraints, except for versions beginning with a dollar sign ('$'); these must be followed byan identifier.

The HEADER instruction is obligatory but its constituent fields are optional. It must be thefirst instruction in the test program. If it is absent, a warning message is generated.

Example HEADER histo, 01a, 01a

BEGIN



ENVIRONMENT / END ENVIRONMENT

Syntax ENVIRONMENT name [ ( param { , param } ) ]END ENVIRONMENT

Description The ENVIRONMENT instruction defines a test environment declaration, i.e. a default setof test specifications.

The name parameter gives the environment a name which is referenced in the USEinstruction.Every environment can have parameters. The different parameters declared can be used ininitialization and expected value expressions. These parameters are initiated by the USEinstruction.

The END ENVIRONMENT instruction marks the end of an environment declaration.

Associated rules An environment must be defined after the BEGIN instruction.Each environment is visible in the block in which it has been declared and in any blocksincluded in this block, after its declaration.An environment can only contain VAR, ARRAY, STR, FORMAT or STUB instructions andconditional generation instructions. If it is empty, a warning message will be generated.name is obligatory. It is any identifier which gives a unique environment name.param must be an identifier.An environment is activated by the USE instruction which defines its scope and its priority.After generating the initializations and the tests of an ELEMENT block, ATTOL includesvisible environments in order of priority, at every END ELEMENT instruction, in order tocomplete the initializations and tests.

Example ENVIRONMENT calcul_histo VAR x1, init = 0, ev = init VAR x2, init = SIZE_IMAGE-1, ev = init VAR y1, init = 0, ev = init VAR y2, init = SIZE_IMAGE-1, ev = init ARRAY histo, init = 0, ev = 0 VAR status, init ==, ev = 0END ENVIRONMENT

See also USE



FAMILY

Syntax FAMILY family_name{ , family_name}

Description The FAMILY instruction enables you to group tests by families or classes.

This instruction appears in a TEST block : it defines the family(-ies) to which the testbelongs.

When starting tests, you can request that just tests of a given family are executed.

The family_name parameter indicates the name of the test family. For example, the followingfamilies can be defined : nominal, structural, robustness.

A test can belong to several families : in this case, the FAMILY instruction contains afamily_name list, separated by commas.

Associated rules The FAMILY instruction must be located before the first ELEMENT block of the TESTblock. It must be unique in the TEST block.

family_name can be any identifier. You must have at least one family name.

The FAMILY instruction is optional. If it is omitted, a warning message is generated and thetest belongs to every family.

Example TEST 1 FAMILY nominal

COMMENT histogram calculation on a black image

ELEMENT



FORMAT

Syntax FORMAT variable = formatFORMAT type = formatFORMAT field = format

Description The FORMAT instruction allows you to change the display format of a tested item. Thisitem can be :

9 a variable,

9 a simple C type declared by typedef (in this case, the display mode will change for allvariables of this type),9 a member of a structure or a C union (in this case, the display mode will change for all

the members of variables of this type).

The new format of the item is described by an optional abstract C type eventually followedby a printing directive for variables of type integer or floating only. The format of theseprinting directives is the following:

# directive [ size ]with the following possibilities, for integers:

9 #h for hexadecimal display,

9 #b for binary display,

9 #u for unsigned decimal display,

9 #d for signed decimal display,

and for floating variables:

9 #f to display without an exponent,9 #e to display with an exponent.

For integers, size is the number of bits to be displayed. For floating variables, size is thenumber of the number of digits after the decimal point.



Associated rules The FORMAT instruction is optional. It must be located after the BEGIN instruction.

It is applicable immediately, only in the block in which it is declared.

variable follows the syntax rules of C. type is a C identifier used in typedef, struct or unioninstructions. format is an abstract C type.

If the change is to be applied to array elements, you can use an abstract C type to describethe new modified variable, field or type.

variable, type or field and format are obligatory. A format cannot be empty: its must containeither the abstract C type, or the printing directive.

In the printing directive, the size is optional. The size must be a multiple of 8 for theintegers. The default values for this size are the following:

9 for the integers, the number of bits of the abstract type if it is given, or if it is not, thenumber of bits of the type or the variable whose printing format is modified,

9 for #f, 6 digits after the decimal point and for #e, 2 digits after the decimal point.

Example #char x;#typedef char *pointer;#pointer p;#char t[10]

FORMAT x = intFORMAT pointer = void* -- modifies pFORMAT t = int[] t is an array of integersFORMAT x = int#h8 -- display in hexa, only 8 bitsFORMAT y = #b -- display in binary without -- modifying the typeFORMAT z = short#u -- display in unsigned decimal

FORMAT f1 = #f -- displays by example 3.670000FORMAT f1 = #f4 -- displays by example 3.6700FORMAT f1 = #e4 -- displays by example 0.36700E1



INCLUDE

Syntax INCLUDE CODE fileINCLUDE PTU file

Description The INCLUDE instruction redirects processing of the ATTOL Test Generator to the file,then, when this is complete, returns it to the current file.

Including a file with the keyword CODE lets you include a C source file without having tostart every line with a hash character ('#').

Including a file with the keyword PTU lets you include a test plan within a test plan.

Associated rules The name of the included file may be specified with an absolute path or a path relative to thecurrent directory.

If the file is not found in the current directory, all directories specified by the -incl option,when the preprocessor is started, will be searched.

If it is still not found or if access is denied, an error will be generated.

The instruction INCLUDE CODE is equivalent to the following line in C :

##include "".

Example INCLUDE CODE file1.cINCLUDE CODE ../file2.c

INCLUDE PTU /usr/attol/test/file3.ptu



INITIALISATION / END INITIALISATION

Syntax INITIALISATIONEND INITIALISATION

Description The INITIALISATION and END INITIALISATION instructions let you provide C code,which will be integrated into the generation as the first C instructions of the test program(first lines of main).

In certain environments, (e.g. a different target machine), this is the means of initializing thetarget machine.

Associated rules An INITIALISATION / END INITIALISATION block must appear after the BEGINinstruction or between two SERVICE blocks.

This block can only contain C code. This code must begin with '#' or @.

There is no limit to the number of INITIALISATION blocks. At generation, they will beconcatenated in the order in which they appeared in the test plan.

See also TERMINATION.



NEXT_TEST

Syntax NEXT_TEST [ LOOP nb]

Description The NEXT_TEST instruction starts a TEST block linked to the previous. It contains onemore ELEMENT blocks. It does not contain the FAMILY instruction.

For this new test, a number of iterations can be specified by the keyword LOOP.

Associated rules The NEXT_TEST instructions can only appear in a TEST / END TEST block.

nb is an C integer expression strictly greater than 1.

Example SERVICE CALCUL_HISTO

# int x1, x2, y1, y2 ;# int status ;# T_HISTO histo;

TEST 1 FAMILY nominal

ELEMENT...

END ELEMENT NEXT_TEST LOOP 2 ELEMENT

See also TEST



STUB

Syntax STUB [stub_name .] function [ call_range => ] ( [val_ param {, param_val } ] ) [return_val ] {, [ call_range => ] ( [ param_val {, param_val } ] ) [ return_val ] }

Description The STUB instruction describes all calls to a simulated function in a test scenario.

The following is described for every parameter of this function and for every expected call :

9 for _in parameters, the values passed to the function; these values will be stored andthen tested after execution,

9 for _out parameters and, where appropriate, the return value, the values returned by thefunction; these values will be stored in order to be returned during execution,

9 for _inout parameters, both the previous two values are required,

9 for _no parameters, nothing is required.

call_range describes one or many calls as follows:

call_num =>call_num .. call_num =>others =>

where call_num is the number of the stub call (begun to 1). The key word other describesall the calls not still described. Moreover, this key word allows to not check the sub callnumber.

Associated rules function is the name of the simulated function. It is obligatory. You must previously havedescribed this function in a DEFINE STUB / END DEFINE STUB block. You can specifyin which stub (stub_name) the declaration was made.param_val is an expression describing the test values for _in parameters and the returnedvalues for _out parameters. For _inout parameters, param_val is expressed in the followingway :

(in_param_val , out_param_val )return_val is an expression describing the value returned by the function if its type is notvoid. Otherwise, no value is provided.

You must give values for every _in, _out and _inout parameter; otherwise, a warningmessage is generated. The _no parameters are ignored.



param_val and return_val are C expressions that can contain :

x numeric (integer or floating-point), character, or character string literal values.Strings can be delimited by single or double inverted commas,

x constants, in the C sense of the word, which can be numeric, characters, or characterstrings,

x ATTOL constants defined by the CONST instruction,

x variables belonging to the test program or the module to be tested,

x C functions,

x the keyword NIL to designate a null pointer,

x pseudo-variables I, I1, I2 ..., J, J1, J2 ..., where In is the current index of the nthdimension of the parameter and Jm the current number of the sub-test generated bythe test scenarios mth INIT IN, INIT FROM or LOOP; the I and I1 variables aretherefore equivalent as are J and J1; the sub-test numbers begin at 1 and areincremented by 1 at each iteration,

x a C expression with one or more of the above elements combined using any of the Coperators (+, -, *, /, %, &, |, ^, &&, ||, ) and casting, with all required levels ofparentheses, and conforming to C rules of syntax and semantics, the + operator beingallowed to concatenate character string variables,

x for arrays and structures, a list of above-mentioned expressions between braces ('{'and '}') or brackets ('[' et ']'),with, where appropriate :) for an array element, part of an array or a structure field, its index, interval or

name followed by '=>' and by the value of the array element, common to allelements of the array portion or structure field,

) the keyword others followed by '=>' and the default value of any array elementsor structure fields not yet mentioned.

You must describe at least one call in the STUB instruction. There can be severaldescriptions, separated by commas (',').STUB instructions can appear in ELEMENT or ENVIRONMENT blocks.



Example STUB open_file ("file1")3STUB create_file ("file2")4STUB read_file (3,"line 1")1, (3,"line 2")1, (3,"")0STUB write_file (4,"line 1")1, (4,"line 2")1STUB close_file 1=>(3)1,2=>(4)1



SERVICE / END SERVICE

Syntax SERVICE service_nameEND SERVICE

Description The SERVICE instruction starts a SERVICE block. This block contains the description ofall the tests relating to a given service of the module to be tested.

The service_name parameter flags the tested service in the test report, and is thereforeusually the name of this service (although this is not obligatory).

The END SERVICE instruction indicates the end of the service block.

Associated rules The SERVICE instruction must appear after the BEGIN instruction.

The service_name parameter can be any identifier. It is obligatory.

Example BEGIN

SERVICE CALCUL_HISTO





IF / ELSE / END IF

Syntax IF condition { , condition }...

ELSE...

END IF

Description The IF, ELSE and END IF instructions allow a conditional generation of the test program.

These instructions enclose instructions that may or may not be included when the test plan isanalyzed depending on the presence of one of the condition conditions in the list provided tothe ATTOL Test Generator by the -define option or in the C #define instructions.The "condition { , condition }" list thus forms a series of conditions that is equivalent tousing an expression of logical ORs.

The IF instruction starts the conditional generation block.

The END IF instruction terminates this block.

The ELSE instruction separates this block into 2 parts, one being included when the other isnot, and vice versa.

Associated rules This block of instructions can appear anywhere in the test program.

condition is any identifier. You must have at least one condition in an IF instruction.

This block can contain ATTOL instructions or C code.

IF and END IF instructions must appear simultaneously.

The ELSE instruction is optional.

The generating rules are as follows :

9 If at least one of the conditions specified in the IF instructions list of conditions appearsin the list associated with the -define option, then the first part of the block is included.9 If none of the conditions specified in the IF instructions list of conditions appear in the

list associated with the -define option, then the second part of the block is included (ifELSE is present).

The IF / ELSE / END IF block is equivalent to the following block in C :



#if defined() { || defined() } ......

#else...

#endif

Example IF test_on_target VAR register, init == , ev = 0ELSE VAR register, init = 0 , ev = 0END IF



SIMUL / ELSE_SIMUL / END SIMUL

Syntax SIMULELSE_SIMULEND SIMUL

Description The SIMUL, ELSE_SIMUL and END SIMUL instructions allow a conditional generationof the test program.

These instructions enclose instructions that may or may not be included, when the testprogram is analyzed by the ATTOL Test Generator, depending on the presence of the-nosimulation option.

The SIMUL instruction starts the conditional generation block.

The END SIMUL instruction terminates this block.

The ELSE_SIMUL instruction separates this block into 2 parts, one being included whenthe other is not, and vice versa.

Associated rules This block of instructions can appear anywhere in the test program.

It can contain ATTOL instructions or C code.

The SIMUL and END SIMUL instructions must both appear or neither must appear.

The ELSE_SIMUL instruction is optional.

The generating rules are as follows :

x if -nosimulation is not present => the first part of the block is included

x if -nosimulation is present => the second part of the block, if it exists, is includedotherwise nothing happens.

For compatibility, ELSE_SIMUL can be replaced by SINON_SIMUL.



Example SIMUL #x = 0;ELSE_SIMUL #x = (type_x *) malloc ( sizeof(*x) );END SIMUL...

SIMULVAR x , INIT = 0 , EV = 1VAR p , INIT = NIL , EV = NONIL

ELSE_SIMULVAR x , INIT = 0 , EV = 0VAR p , INIT = NIL , EV = NIL

END SIMUL



TERMINATION / END TERMINATION

Syntax TERMINATIONEND TERMINATION

Description The TERMINATION and END TERMINATION instructions delimit a block of nativecode which is integrated into the generation process as the last C instructions to be executed(last lines of main).

In certain environments (e.g. a different target machine), this is the means of terminatingexecution on the target machine.

Associated rules A TERMINATION / END TERMINATION block must appear after the BEGINinstruction and outside any SERVICE block.

This block can only contain C code. This code must begin with '#' or @.

There is no limit to the number of TERMINATION blocks.. They will be concatenated atgeneration.

Example INITIALISATION



TEST / END TEST

Syntax TEST test_name [ LOOP nb]END TEST

Description The TEST instruction starts a TEST block. This block describes the test case for a service.It contains one more ELEMENT blocks specifying the test.

In the test report, the test_name parameter flags the test within the SERVICE block. Testsare usually given numbers in ascending order.

A number of iterations can be specified for each test by the keyword LOOP.

The END TEST instruction marks the end of the TEST block.

Associated rules The TEST and END TEST instructions can only appear in a SERVICE block.

test_name is obligatory. If it is absent, ATTOL generates an error message.

nb is a C integer expression strictly greater than 1.

Example SERVICE CALCUL_HISTO



ELEMENT

See also ELEMENT, SERVICE



TYPE_SERVICE

Syntax SERVICE_TYPE type { , type }

Description The SERVICE_TYPE instruction indicates in the test report the type of service tested. Youdecide the values of type. It is generally used to specify if the tested service is internal orexternal.

If SERVICE_TYPE appears in a SERVICE block, it indicates the corresponding type ofservice.

If it occurs outside any SERVICE block, it is, by default, applied to all the services which donot contain a SERVICE_TYPE instruction.

Associated rules The SERVICE_TYPE instruction is optional.

It can be located either before the first SERVICE block or before the first TEST block.

type can be any identifier.

Example SERVICE_TYPE internal, external

SERVICE countSERVICE_TYPE internal



USE

Syntax USE name [ ( expression { , expression } ) ]

Description The USE instruction activates a test environment that is defined using theENVIRONMENT instruction.

The position of the USE instruction determines which tests are affected by the environmentused :

9 If USE occurs outside a SERVICE block, the instructions contained in thisenvironment will be applied to all subsequent ELEMENT blocks.

9 If USE occurs within a SERVICE block and outside a TEST block, the instructionscontained in this environment will be applied to all subsequent ELEMENT blocks ofthis SERVICE block.

9 If USE occurs within a TEST block and outside an ELEMENT block, the instructionscontained in this environment will be applied to all subsequent ELEMENT blocks ofthis TEST block.

9 If USE occurs within an ELEMENT block, the instructions contained in thisenvironment will only be applied to this block.

The fact that the USE instruction can appear at these 4 different levels gives rise to 4priority levels, from outside a SERVICE block (the lowest priority) to inside anELEMENT block (the highest priority).

Within the same priority level, the last USE instruction is the one with the highest priority.

ATTOL completes the testing in accordance with these priority rules, and on the basis thatvariables tested several times are included in the environment with the highest priority.

This is also true for every element of arrays described in extended mode.

If the environment it references takes parameters, the USE instruction must initialize theseparameters using C expressions.



Associated rules The USE instruction can appear after BEGIN and outside an ENVIRONMENT block, afterthe definition of the environment it references.

name is the name of an environment declared by the ENVIRONMENT instruction.

expression must be an expression that conforms to C syntax and semantics.

Example ENVIRONMENT calcul_histo VAR x1, init = 0, ev = init VAR x2, init = SIZE_IMAGE-1, ev = init VAR y1, init = 0, ev = init VAR y2, init = SIZE_IMAGE-1, ev = init ARRAY histo, init = 0, ev = 0 VAR status, init ==, ev = 0END ENVIRONMENTUSE calcul_histo

See also ENVIRONMENT.



VAR / ARRAY / STR

Syntax VAR variable , initialisation , expected_valueARRAY variable , initialisation , expected_valueSTR variable , initialisation , expected_valueVAR expression , expected_valueARRAY expression, expected_valueSTR expression, expected_value

Description The VAR, ARRAY and STR instructions describe the behaviour of variables in the test,i.e. they specify their initial values and the expected values at the end of the test and thebehavior of test expressions, i.e. they specify their expected values only.

Associated rules The VAR, ARRAY and STR instructions can only appear in an ELEMENT block or anENVIRONMENT block.

These three instructions enable any type of C variable, simple variable, array or structuredvariable to be tested. Using a VAR, ARRAY or STR instruction will change the way inwhich the result of the variable test is displayed in the test report.

They enable too any expression whose type is simple.

The variable parameter

Description variable is the name of the C variable that is to be tested. C syntax has been modified so thatarrays can be easily tested. This consists of specifying the upper and lower bounds of therange of the test for each dimension of the array in the following way :

[ .. ]

Associated rules variable can be a simple variable (integer, floating-point number, character, pointer orcharacter string), an element of an array or structure, part of an array, an entire array or acomplete structure.

If the variable is an array for which no test bounds have been specified, ATTOL tests all thearray elements. Similarly, if the variable is a structure of which one of the fields is an array,ATTOL tests all elements of this field.

The variable must have been declared in C beforehand.



Example VAR x, ...VAR y[4], ...VAR z.field, ...VAR p->value, ...ARRAY y[0..100], ...ARRAY y, ...STR z, ...STR *p, ...

The expression parameter

Description expression is a C expression that is to be tested.

Associated rules expression is a C expression, syntactically et semantically correct, whose result type is asimple (integer, floating-point number, character, pointer, character string, ...),

Example VAR x+y, ...VAR sin(z), ...

The initialisation parameter

Description initialisation specifies the initial value of the variable, and appears in one of the followingforms :

x INIT = exp

x INIT IN { exp , exp , ... }x INIT ( variable ) WITH { exp , exp , ... }x INIT FROM exp TO exp STEP exp

x INIT FROM exp TO exp NB_TIMES nb

x INIT FROM exp TO exp NB_RANDOM nb [+ BOUNDS]x INIT ==

where exp is a C expression that can take :



x numeric (integer or floating-point), character, or character string literal values. Stringscan be delimited by single or double inverted commas,

x constants, in the C sense of the word, which can be numeric, characters, or characterstrings,

x ATTOL constants defined by the CONST instruction,

x variables belonging to the test program or the module to be tested,

x C functions,

x the keyword NIL to designate a null pointer,

x pseudo-variables I, I1, I2 ..., J, J1, J2 ..., where In is the current index of the nthdimension of the parameter and Jm the current number of the sub-test generated bythe test scenarios mth INIT IN, INIT FROM or LOOP; the I and I1 variables aretherefore equivalent as are J and J1; the sub-test numbers begin at 1 and areincremented by 1 at each iteration,

x a C expression with one or more of the above elements combined using any of the Coperators (+, -, *, /, %, &, |, ^, &&, ||, ) and casting, with all required levels ofparentheses, and conforming to C rules of syntax and semantics, the + operator beingallowed to concatenate character string variables,

x for arrays and structures, a list of above-mentioned expressions between braces ('{'and '}') or brackets ('[' et ']'),with, where appropriate :) for an array element, part of an array or a structure field, its index, interval or

name followed by '=>' and by the value of the array element, common to allelements of the array portion or structure field,

) the keyword others followed by '=>' and the default value of any array elements orstructure fields not yet mentioned.

x for INIT IN and INIT WITH only, a list of values, delimited by braces ('{' et '}') orbrackets ('[' et ']'), composed of above-defined expressions,

and where nb is an integer constant that is either literal or derived from an expressioncontaining C constants or ATTOL constants.

The integers contained in an expression can be written in accordance with C lexical rules or



as follows :

x hex_integerH for hexadecimal values; the integer must be preceded by 0 if it beginswith a letter,

x binary_integerB for binary values.

INIT = exp initializes variable before the test with the value exp.

INIT IN { exp, exp, ...} declares a list of initial values. This is a condensed form of writingthat enables several tests to be contained within a single instruction.

INIT ( variable ) WITH { exp, exp, ...} declares a list of initial values which will be assignedin correlation with those of the variable initialized by an INIT IN instruction. There must bethe same number of initial values.

INIT FROM exp TO exp allows the initial value of a numerical variable (integer orfloating-point) to vary within two bounds :x by successive steps (STEP),x by taking a number of values that are equidistant between the 2 bounds (NB_TIMES),x by taking a number of values at random between the 2 bounds, including, where

appropriate, the bounds (NB_RANDOM).

nb has the following constraints :

x for NB_TIMES : nb >= 2,

x for NB_RANDOM : nb >= 1,

INIT == allows the variable to be left uninitialized. You can thus control the values ofvariables that are dynamically created by the service under test. The initial value displayed inthe test report is then '?'.

An initialization expression is permitted (INIT == exp). It will be included in expressions ofexpected values if the INIT pseudo-variable is used.

Associated rules INIT IN and INIT (variable) WITH are not allowed for arrays initialized in extended modeand for structures.

INIT FROM is only allowed for numeric variables.



Example VAR x, INIT = pi/4-1, ...VAR y[4], INIT IN { 0, 1, 2, 3 }, ...VAR y[5], INIT(y[4]) WITH { 10, 11, 12, 13 }, ...VAR z.field, INIT FROM 0 TO 100 NB_RANDOM 3, ...VAR p->value, INIT ==, ...ARRAY y[0..100], INIT = sin(I), ...ARRAY y, INIT = {50=>10,others=>0}, ...STR z, INIT = {0, "", NIL}, ...STR *p, INIT = {value=>4.9, valid=>1}, ...

The expected value parameter

Description expected_value specifies the expected value of the variable at the end of the test, and canappear in one of the following forms :

x EV = exp

x EV = exp , DELTA = tolerance

x MIN = exp , MAX = exp

x EV IN { exp , exp , ... }x EV ( variable ) IN { exp , exp , ... }x EV ==

x EV =>identifier

where exp is similar to initialization expressions with the additional possibility of using :

x the pseudo-variable INIT, which copies the initialisation expression,

x the keyword NONIL, which tests if a pointer is non-null.

And where tolerance can be expressed :

x as an absolute value, by a numerical expression in the form described above,

x as a percentage of the expected value. tolerance is then written in the form exp %.

EV = exp specifies the expected value of the variable when it is known in advance. The



value of variable is deemed to be correct if it is equal to exp.EV = exp, DELTA = tolerance allows a tolerance for the expected value. The value ofvariable is deemed to be correct if it lies between exp - tolerance and exp + tolerance.MIN = exp , MAX = exp specifies a correctness interval, delimited by the two expressions.The value of variable is deemed to be correct if it lies between the two expressions.Characters and characters strings are treated in dictionary order.EV IN { exp , exp , ... } specifies the values expected successively, in accordance with theinitial values, for a variable that is declared in INIT IN. It is therefore essential that the twolists have an identical number of values.EV ( variable ) IN is identical to EV IN, but the expected values are a function of anothervariable that has previously been declared in INIT IN. As for EV IN, the two lists must havean identical number of values.EV == allows the value of variable not to be checked at the end of the test. Instead, thisvalue is read and displayed. The value of variable is always deemed to be correct.EV => allows the expected value of variable to be assimilated, when the -learn option isused.

Associated rules EV with DELTA is only allowed for numeric variables.MIN = exp , MAX = exp is only allowed for alphanumeric variables that use lexicographicalorder for characters and character strings.MIN = exp , MAX = exp is not allowed for pointers.Only EV = and EV ==.are allowed for structured variables.

Example VAR x, ..., EV = pi/4-1VAR y[4], ..., EV IN { 0, 1, 2, 3 }VAR y[5], ..., EV(y[4]) IN { 10, 11, 12, 13 }VAR z.field, ..., MIN = 0, MAX = 100VAR p->value, ..., EV ==ARRAY y[0..100], ..., EV = cos(I)ARRAY y, ..., EV = {50=>10,others=>0}STR z, ..., EV = {0, "", NIL}STR *p, ..., EV = {value=>4.9, valid=>1}

) Sometime, to avoid generated code compilation warning, cast must be inserted before NIL or NONILkeywords.



2.3. FRENCH VERSION

The ATTOLLAN environment variable allows either a French or English version of ATTOL to be used. It canhave the following values :

x FR or FA ATTOL language in French

x GB ATTOL language in English (default value)

The two languages have identical rules of syntax and semantics. It is the keywords that are different.

FRENCH ENGLISH FRENCH ENGLISHA TO MAX MAX

AVEC WITH MIN MINBOUCLE LOOP STUB STUBBORNES BOUNDS NB_HASARD NB_RANDOM

CODE CODE NB_VALEUR NB_TIMESCOMMENT COMMENT PTU PTU

CONST CONST SERVICE SERVICEDANS IN (*) SI IF

DE FROM SIMUL SIMULDEBUT BEGIN SINON ELSE

DEFINIR DEFINE SINON_SIMUL ELSE_SIMUL (*)ELEMENT ELEMENT STR STRENTETE HEADER TAB ARRAY

ENVIRONNEMENT ENVIRONMENT TERMINAISON TERMINATIONFAMILLE FAMILY TEST TEST

FIN END TEST_SUITE NEXT_TESTFORMAT FORMAT TYPE_SERVICE SERVICE_TYPEINCLURE INCLUDE UTILISE USE

INCREMENT STEP VA EV (*)INIT INIT VAR VAR

INITIALISATION INITIALIZATION

Keywords marked with (*) are allowed in both French and English for compatibility with previous versions.

ATTOL UniTest The C analyzer


3. THE C ANALYZER

The preprocessor and the test plan generator include a C analyzer that :

9 preprocesses, in the C sense of the word, any C code found.

9 analyzes the preprocessed C code.

3.1. THE C PREPROCESSOR

3.1.1. Grammar of the C preprocessor

The C preprocessor incorporated in ATTOL only analyzes those lines in the test plan which begin with two hashcharacters (##) in the first column, and those lines in C files which begin with a hash character (#) in the firstcolumn. The preprocessor respects the following rules of grammar for these lines :

directives ::= { directive }directive ::= conditional_gen |

ontrol_directive

conditional_gen ::= if_directive { elseif_directive } [ else_directive ] endif_directiveif_directive ::= if constant_exp |

fdef identifier |fndef identifier

elseif_directive ::= elif constant_exp

else_directive ::= else

endif_directive ::= endif

control_directive ::= include "string" |nclude < string > |efine identifier [ = string ] |efine identifier ( ident_list ) string |ndef identifier |ragma attol attol_command |ragma string |ther_directives

ident_list ::= identifier { , identifier }



other_directives : ignored by ATTOL : end of line

constant_exp : C expression described in the section C expressions with the following additiona

## : concatenation of identifiers,defined() : returns a 1 if is defined,# : transforms into a character string.

3.1.2. Predefined constants

The C preprocessor predefines seven constants which are updated dynamically as the code is analyzed.

__DATE__ current date in the format "mmm dd yyy",__TIME__ current time in the format "hh:mm:ss",__FILE__ name of the file being analyzed__STDC__ 1 if RESTRICTION=ANSI, otherwise not defined,__LINE__ current line number in the file being analyzed.__BASE_FILE__ name of the file initiating analysis,__INCLUDE_LEVEL__ current include level.

) If the compiler being used defines __STDC__ as 0, the default value can be replaced in the standarddefinitions file by the commands :

#undef __STDC__#define __STDC__ 0

3.1.3. ATTOL pragmas

ATTOL pragmas modify the operation of the C analyzer, which is described in the following section. Thesepragmas all begin with pragma attol and are followed by one of the following commands :

incl_std = ,... Modifies the default include directories

stop_analyse Stops C code analysis

start_analyse Restarts C code analysis



sizeof ( ) = orsizeof =

Modifies the size of an integer type that ispredefined or defined by a typedef

signof ( ) = signed | unsigned Modifies the sign extension of an integer typethat is predefined or defined by a typedef

type_modifier = identifier defines a type modifier

"" = "" equates a pragma to a new command of the Cpreprocessor

3.2. GRAMMAR OF THE C ANALYZER

The C analyzer only analyzes those lines which begin with a hash character (#) and which appear either beforethe BEGIN instruction or after this instruction between each SERVICE block.

You can insert C source code, which will not be analyzed, by beginning the line with a @ character instead of a#.

The grammar of the C analyzer is as follows :

declaration ::= decl_spec [ init_decl_list ] ; |decl_list

decl_spec ::= storage_class [ decl_spec ] |type_spec [ decl_spec ]

init_decl_list ::= declaration_with_init { , declaration_with_init }declaration_with_init ::= declarator[ asm ] [ attribute ] [ = initialisation ]initialisation : not analyzed by ATTOLasm ::= asm ( assembler ) |

__asm ( assembler ) |__asm__ ( assembler )

assembler : not analyzed by ATTOLattribute ::= attribute ( text_attribute ) |

__attribute ( text_attribute ) |__attribute__ ( text_attribute )

text_attribute : not analyzed by ATTOLstorage_class ::= typedef |



extern |static |auto |register

type_spec ::= type_modifier |char |short |int |long |signed |__signed |__signed__ |unsigned |float |double |const |__const |__const__ |volatile |__volatile |__volatile__ |void | union_struct_spec |enum_spec |typedef_name

type_modifier : recorded by ATTOL due to the type_modifier pragmatypedef_name : recorded by ATTOL at each typedefunion_struct_spec ::= union_or_struct [ identifier ] { struct_field_list } |

union_or_struct identifier |union_or_struct type_name

union_or_struct ::= union |struct

struct_field_list ::= { struct_fields }struct_fields ::= type_spec_list fields_list ;

type_spec_list ::= { type_spec }fields_list ::= field { field }field ::= declarator |

[ declarator ] : sizesize : not analyzed by ATTOLenum_spec ::= enum [ identifier ] { enum_list ] |

enum identifier

enum_list ::= enum_id { , enum_id }



enum_id ::= identifier |identifier = enum_value

enum_value : not analyzed by ATTOLdeclarator ::= [ pointer ] direct_declaratordirect_declarator ::= identifier |

( declarator ) |direct_declarator [ [ dimension ] ] |direct_declarator ( parameter_list_type ) |direct_declarator ( [ identifiers_list ] )

identifiers_list ::= identifier { , identifier }pointer ::= { * type_spec_list }parameter_list_type ::= parameters_list [ , ... ]parameters_list ::= param_decl { , param_decl }param_decl ::= decl_spec declarator |

decl_spec [ abstract_decl ]nom_de_type ::= liste_spcif_type [ abstract_decl ]abstract_decl ::= pointer |

[ pointer ] direct_abstract_decldirect_abstract_decl ::= ( abstract_decl ) |

[direct_abstract_decl ] [ [ dimension ] ] |[direct_abstract_decl ] ( [ parameter_list_type ] )

function_body ::= { instructions }instructions : not analyzed by ATTOLdecl_list ::= decl_list2 { decl_list2 }decl_list2 ::= type_spec_list delarators_list ; |

register delarators_list ; |register type_spec_list delarators_list ; |type_spec_list register delarators_list ; |auto delarators_list ; |auto type_spec_list delarators_list ; |type_spec_list auto delarators_list ;

delarators_list ::= declarator { , declarator }C_code ::= { external_def }external_def ::= function_def |

declaration |asm

function_def ::= [ delc_spec ] declarator functionfunction ::= [ decl_list ] function_body



The grammars entry point is C_code.

3.3. C EXPRESSIONS

The expressions contained in the INIT and EV instructions respect the following rules of grammar :

primary_exp ::= identifier |constant |string |[ expression ]

postfixed_exp ::= primary_exp |postfixed_exp [ expression ] |postfixed_exp [ expression .. expression ] |postfixed_exp ( [ expressions_arg_list ] ) |postfixed_exp . identifier |postfixed_exp -> identifier

expressions_arg_list ::= assignment_exp { , assignment_exp }unary_exp ::= postfixed_exp |

sizeof unary_exp |sizeof ( type_name ) |alignof unary_exp |__alignof unary_exp |__alignof__ unary_exp |& cast_exp |* cast_exp |+ cast_exp |- cast_exp |~ cast_exp |! cast_exp

cast_exp ::= unary_exp |( type_name ) cast_exp

multiplicative_exp ::= cast_exp |multiplicative_exp * cast_exp |multiplicative_exp / cast_exp |multiplicative_exp % cast_exp

additive_exp ::= multiplicative_exp |additive_exp + multiplicative_exp |additive_exp - multiplicative_exp

shift_exp ::= additive_exp |shift_exp



shift_exp >> additive_exp

relation_exp ::= shift_exp |relation_exp < shift_exp |relation_exp > shift_exp |relation_exp = shift_exp

equality_exp ::= relation_exp |equality_exp == relation_exp |equality_exp != relation_exp

and_exp ::= equality_exp |and_exp & equality_exp

exclusive_or_exp ::= and_exp |exclusive_or_exp ^ and_exp

inclusive_or_exp ::= exclusive_or_exp |inclusive_or_exp | exclusive_or_exp

logical_and_exp ::= inclusive_or_exp |logical_and_exp && inclusive_or_exp

logical_or_exp ::= logical_and_exp |logical_or_exp || logical_or_exp

condition_exp ::= logical_or_exp |logical_or_exp ? logical_or_exp : condition_exp

assignment_exp ::= condition_exp

expression ::= assignment_exp |expression , assignment_exp

attol_init ::= exp_attol |condition_exp => attol_exp |condition_exp .. condition_exp => attol_exp

attol_exp ::= assignment_exp |{ attol_init { , attol_init } } |[ attol_init { , attol_init } ]

The grammars entry point is attol_exp.

3.4. LEXICAL ELEMENTS

3.4.1. Identifiers

The following identifiers are recognized :



identifier ::= nondigit { nondigit | digit }nondigit ::= a | b | ... | z | A | B | ... | Z | _ | $digit ::= 0 | 1 | ... | 9

3.4.2. Constants

The following constants are recognized :

constant ::= real_constant |integer_constant |enum_constant |character_constant

real_constant ::= fraction [ exponent ] [ suffix ] |digits exponent [ suffix ]

exponent ::= e | E [ + | - ] digitssuffix ::= f | F | l | Lfraction ::= [ digits ] . digits |

digits .

digits ::= digit { digit }integer_constant ::= decimal_constant [ suffix2 ] |

octal_constant [ suffix2 ] |hexa_constant [ suffix2 ] |attol_hexa_constant |attol_binary_constant

suffix2 ::= u | U [ l | L ] |l | L [ u | U ]

decimal_constant ::= digit_other_than_0 { digit }digit_other_than_0 ::= 1 | 2 | ... | 9octal_constant ::= 0 octal_digit { octal_digit }octal_digit ::= 0 | 1 | ... | 7hexa_constant ::= 0x | 0X hexa_digit { hexa_digit }hexa_digit ::= 0 | 1 | ... | 9 | a | b | ... | f | A | B | ... | Fattol_hexa_constant ::= digit { hexa_digit } Hattol_binary_constant ::= 0 | 1 { 0 | 1 } B



enum_constant ::= identifier

character_constant ::= ' c_char { c_char } ' |L ' c_char { c_char } '

c_char ::= any ASCII character except quote (') and backslash (\) |escape_character

escape_character ::= \' | \" | \\ | \ octal_constant | \a | \b | \f | \n | \r | \t | \v |\x hexa_digit { hexa_digit }

3.4.3. Character strings

The following character strings are recognized :

string ::= " s_char { s_char } " |L " s_char { s_char } "

s_char ::= any ASCII character except double quotes (")and backslash (\) |escape_character

ATTOL UniTest The ATTOL Test Generator


4. THE ATTOL TEST GENERATOR

4.1. COMMAND

attolpreproC

[ ][ -learn ][ -target= ][ -command= ][ -compress ][ -const= ][ -std_define= ][ -define= [ = ] { , [ = ] } ][ -data= ][ -exfamily= { , } ][ -expand ][ -exservice= { , } ][ -extest= { , } ][ -family= { , } ][ -fast | -nofast ][ -incl= { , } ][ -noanalyse ][ -noedit ][ -nopath ][ -nosimulation ][ -restriction=ANSI | KR ][ -rename= ][ -service= { , } ][ -source=][ -strver=][ -syscomp=DOS | OS2 | VMS | UNIX ][ -symbtab= ][ -test= { , } ][-version= ]

or



attolpreproC @

) The options can be in any order, they can be in upper or lower case,

) Under DOS, the options may begin with a slash ('/'), and attolpreproC is replaced by atprec,) The environment variable ATUDIR should be defined as the directory containing the ATTOL binaries,

) The environment variable ATUTGT as the directory where are located the target package from your delivery.

Example of environment variables setting under UNIX :

export ATUDIR=/usr/atu/v34/sun4/sunOS5/binexport ATUTGT=/usr/atu/v34/target/csolaris



Description This is a mandatory parameter that specifies the name of the test plan in ATTOL language.

Characteristics You can use any file name extension. If no file name extension is specified, the ATTOL TestGenerator adds the extension specified in the ATTOLPTU environment variable, or thedefault extension .ptu.

The root of this file (name without the extension) is used for the name of the list of errors(which has the default file name extension .lis).

If this test plan is absent or read access is denied, a fatal error is generated and thepreprocessor stops.

Example atprec tests\gen.ptu ... (DOS)attolpreproC tests/gen.ptu ... (UNIX)

File tests\gen.ptu (DOS) or tests/gen.ptu (UNIX) is analyzed.

attolpreproC gen ...

File gen.ptu is analyzed.

attolpreproC gen.fic ...

File gen.fic is analyzed



< generated file >

Description This is a mandatory parameter that specifies the name of the C test program that is generatedfrom the test plan.

Characteristics You can use any file name extension. If no file name extension is specified, the ATTOL TestGenerator adds the extension .c.

The root of this file (name without the extension) is used for the name of the include file inthe test program (file name extension .ic), the name of the symbol table file (default filename extension .tdc) and the name of the trace file generated during the execution of the test(default file name extension .rio).

If it is not possible to create one of the.c, .ic or .tdc files, a fatal error is generated and thepreprocessor stops.

Example attolpreproC gen.ptu code ...

After the execution of the ATTOL Test Generator, generatedcode is included in "code.c" file.



Description This is an optional parameter that specifies the directory on the target machine where thetrace file that is generated by ATTOL runtime when running the test will be stored.

Default option If this parameter is absent, the trace file will be created in the same directory as the testprogram.

Characteristics This parameter must be within quotes (") if it contains one or more dashes '-' or slashes '/'. Itmust be in a syntax that can be recognized by the target machines operating system.

If the machine on which the trace file is created is a UNIX or Domain/OS system, thedirectory name must end with a slash ('/').

If the machine on which the trace file is created is a DOS, the directory name must end witha backslash ('\)'.

If the machine on which the trace file is created is a VMS machine, the full directory pathmust be given.

Example attolpreproC gen.ptu code "/root/repertoire/" ...

Trace file is created in directory /root/directory/ on thetarget machine.

atprec gen.ptu code "repertoire\" ...

Trace file is created in directory\ on the target machine.

attolpreproC gen.ptu code "dsk$test:[test.attol]" ...

Trace file is created in directory dsk$test:[test.attol] onthe target machine.



-learn

Description The -learn option enables the ATTOL Test Generator to assimilate the expected values ofvariables tested with :

ev => identifier.

When this option is used, the data option is obligatory.

Characteristics This option enables the expected values of variables tested with ev => to be assimilated. Inthis case, there is no actual test and the variable is considered not to have been tested (ev==).

Default option By default, the learn mode is not used. Data tested with ev => must have been assimilated ata previous execution.

Example attolpreproC gen.ptu code -learn -data=data.ptu



-target=

Description The -target option determines the type of machine on which the tests are to be run.

Characteristics nom cible can take any value. This value will appear in the output report.

This option lets you define the execution target you wish to use.

The part of the test code that is specific to this target machine is processed at RUNTIME.

Default option The default target machine is the machine on which ATTOL is executed.

Example attolpreproC gen.ptu code -target=VME335



-command=

Description The files generated by ATTOL have a standard header containing in particular the commandthat starts the ATTOL Test Generator.

The -command option lets you send a different command line to the ATTOL Test Generator.

Characteristics This command line is stored in the correspondence table file, and then displayed in the testreport in place of the command used to start the ATTOL Test Generator.

This means that you can show any other type of information in the test reports.

Default option By default, the command used to start the ATTOL Test Generator is kept in the test reports.

Example attolpreproC gen code -command="ATTOL SOFTWARE WORKSHOP"

The command in the test report header is then :

* Command line of the tool : ATTOL SOFTWARE WORKSHOP *



-compress

Description The -compress option tells the ATTOL Test Generator to interpret the VAR and ARRAYinstructions like STR instructions.

Arrays and structured variables tested with the VAR instruction are globally tested, whichmakes the output reports more concise.

Characteristics Choosing this option speeds up the execution of the tests slightly as global checks areperformed on every array and structured variable.

This option has the opposite effect to the -expand option.

Default option By default, VAR and ARRAY instructions are not interpreted like STR instructions.

Example attolpreproC gen.ptu code -compress



-const=

Description This option lets you specify the file where you wish to generate the constants declared by theCONST instruction in the test plan.

Characteristics You can use any file name extension. If no extension is specified, the ATTOL TestGenerator adds the extension .c.

Default option By default, the constants file is not generated.

Example attolpreproC gen.ptu code -const=const ...

File const.c is generated



- std_define =

Description This option provides ATTOL with a file of C definitions, which describes the characteristicsof the compiler used.

This file enables ATTOL to duplicate the behaviour of the C compiler when C codeincorporated in the test plan is being analyzed.

Characteristics This option is only included if the -noanalyse option is not present.

If the file provided cannot be found, a fatal error is generated and the ATTOL TestGenerator stops.

As a general rule, one or more generic standard definitions files are provided with ATTOLruntimes.

Dedault option By default, characteristics of the compiler are not included.

Example attolpreproC gen.ptu code -std_define=csun.def



-define=[=]{,[=]}

Description This option specifies a list of conditions to be applied when the ATTOL Test Generatorstarts.

These conditions let you :

9 conditionally generate the test program,

9 define identifiers for the C preprocessor. In this case, this option is equivalent to option-D of the compiler.

You can either just define the conditions, (the default value is 1), or else give them a value(-define==).

Characteristics The identifiers specified by the -define option apply conditions to the generation of any IF /ELSE / END IF blocks in the test plan.

If the option is present together with one of the conditions specified in the IF instruction, theIF / ELSE block (if ELSE is present) or the ELSE / END IF block (if ELSE is not present) isanalyzed and generated. The ELSE / END IF block is eliminated.

If the option is not present or if none of the conditions specified in the IF instruction aresatisfied, the ELSE / END IF block is analyzed and generated.

Moreover, all symbols defined by this option are equivalent to the following line in C

#define [ ]

Default option By default, the ELSE / END IF blocks are analyzed and generated.

Example attolpreproC gen.ptu code -define=state1



-data=

Description The -data option tells the ATTOL Test Generator the name of the file containing theconstants that have been or are to be assimilated.

This option is obligatory when the -learn option is present or when test plan variables aretested by ev =>.

Characteristics If the learn option is used and the specified file does not exist, it is created. If it exists, it isupdated. If it cannot be created or updated, an error is generated.

If the -learn option is not used, the specified file is analyzed like a file included in the testplan. If read access is denied, an error is generated.

Default option By default, no file is analyzed.

Example attolpreproC gen.ptu code -data=data.ptu



-exfamily={,}

Description This option specifies a list of families of tests that are not to be performed.

Characteristics The ATTOL Test Generator generates the source code related to all families except thosespecified.

This option and the -family option are mutually exclusive.

The names of families are separated by a comma.

If you specify an unknown family in the test plan, the ATTOL Test Generator displays awarning message at the end of execution.

Default option By default, all families are selected.

Example attolpreproC gen.ptu code -exfamily=robustness

attolpreproC gen code -exfamily=robustness,nominal



-expand

Description The -expand option tells the ATTOL Test Generator to interpret the ARRAY and STRinstructions like VAR instructions.

Arrays and structured variables tested with the ARRAY and STR instructions are detailed, i.e.tested element by element and field by field, which makes the output reports more complete.

Characteristics Choosing this option slows down the execution of the tests slightly as checks are performedon every element in the arrays and every field in the structured variables.

This option has the opposite effect to the -compress option.

Default option By default, ARRAY and STR instructions are not interpreted like VAR instructions.

Example attolpreproC gen.ptu code -expand



-exservice={,}

Description This option specifies a list of services that are not to be executed.

Characteristics The ATTOL Test Generator generates the source code related to all services except thosespecified.

This option and the -service option are mutually exclusive.

The names of services are separated by a comma.

If you specify an unknown service in the test plan, the ATTOL Test Generator displays awarning message at the end of execution.

Default option By default, all services are selected.

Example attolpreproC gen.ptu code -exservice=add_str

All services except add_str are selected

attolpreproC gen code -exservice=add_str,diff_str

All services except add_str and diff_str are selected



-extest={,}

Description This option specifies a list of tests that are not to be performed.

Characteristics The ATTOL Test Generator generates the source code related to all tests except thosespecified.

This option and the -test option are mutually exclusive.

The names of tests are separated by a comma.

If you specify an unknown test in the test plan, the ATTOL Test Generator displays awarning message at the end of execution.

Default option By default, all tests are selected.

Example attolpreproC gen.ptu code -extest=5

All tests except those with name "5" are selected

attolpreproC gen.ptu code -extest=1,5

All tests except those with name "1" or "5" are selected



-family={,}

Description This option specifies a list of families of tests that are to be performed.

Characteristics The ATTOL Test Generator only generates the source code related to these families.

This option and the -exfamily option are mutually exclusive.

The names of families are separated by a comma.

If you specify an unknown family in the ATTOL language file, the ATTOL Test Generatordisplays a warning message at the end of execution.

Default option By default, all families are selected.

Example attolpreproC gen.ptu code -family=robustness

attolpreproC gen code -family=robustness, nominal



-fast | -nofastDescription This option optimizes test plan analysis.Characteristics The -fast option tells the ATTOL Test Generator to analyze only those tests you wish to be

generated.

This option speeds up the operation of the ATTOL Test Generator considerably when theoption for selecting tests, services or families is used.

It is thus recommended to use this option as a general rule and especially when -service,-exservice, -family, -exfamily, -test, and -extest options are used.

Default option The -fast option is selected by default.

If you want a full test plan analysis, this option can be deselected using the -nofast option.

Example attolpreproC gen.ptu code -fast



-incl={,}

Description This option provides the ATTOL Test Generator with a list of directories in which theinclude files are stored.

Characteristics Using this option enables ATTOL to :

9 establish the list of include files in the tested source file.

9 execute the ATTOL include instructions,

9 execute the C include instructions (#include).

ATTOL include files are searched for in the current directory first and then in the directorieson the list.

C include system files (#include ) are searched for in the default directory, as follows :

x /usr/include in UNIX,

x none in DOS.

Or in the list of directories provided to ATTOL by the pragma attol incl_std.

C include non-system files (#include "file") are searched for in the current directory first,then in the directories on the list, and then finally in the default directory, as follows :

x /usr/include in UNIX,

x none in DOS.

or in the list of directories provided to ATTOL by the pragma attol incl_std.

Default option By default, the only search directory for ATTOL files is the current directory

Example attolpreproC gen.ptu code -incl=..,attol/incl



-language=

Description This option determines the language in which the tests will be generated.Attol UniTest V3.1 compatibilityUsing attolprepro and attolstart launch scripts

Characteristics language takes the value C

Default option The default generation language is C.

Example attolprepro gen.ptu code -language=c ...



-noanalyse

Description This option disables the C analyzer.

Characteristics By default, lines of C code are analyzed. You can use ATTOL versions, previous to version3.0, via this option.

Default option By default, lines of C code will be analyzed.

Example attolpreproC gen.ptu code -noanalyse ...

C lines are not analyzed



-noedit

Description This option limits test code generation to the initialization of variables.

This makes it possible to generate tighter code for certain special purposes, e.g. debug.

Characteristics If the -noedit option is used, a test report can not be obtained.

Default option By default, code is generated normally.

Example attolpreproC gen.ptu code -noedit



-nopath

Description This option allow to do not generate complete file pathnames on the open and closeexecution trace file call, and on the runtime header file include directive.

Characteristics This option could be used in case of embedded target

Default option By default, complete pathnames are generated.

Example attolpreproC gen.ptu code -nopath ...



-nosimulation

Description This option determines the conditional generation of C code, related to simulation, in thesource file generated by the ATTOL Test Generator.

Characteristics Blocks delimited by the keywords SIMUL, ELSE_SIMUL, END SIMUL may be included inthe files written in ATTOL language.

SIMUL / END SIMUL blocks may also be included.

If the option is present, the code between the keywords ELSE_SIMUL and END SIMUL (ifELSE_SIMULis present) is analyzed and generated. The blocks SIMUL / ELSE_SIMUL andSIMUL / END SIMUL (if ELSE_SIMUL is not present) are eliminated.

Default option By default, the code between the keywords SIMUL and ELSE_SIMUL is analyzed andgenerated. The SIMUL, END SIMUL blocks are analyzed in their entirety.

Example attolpreproC gen.ptu code -nosimulation



-restriction=ANSI | KRDescription The -restriction option lets you modify C code analysis in the test plan according to two

criteria :

Characteristics The possible restrictions are as follows :

ANSI enables C code to be analyzed according to the ANSI standard,

KR enables C code to be analyzed according to the KERNIGHAN & RITCHIE (version2) standard.

These two choices are incompatible with one another.

Default option By default both syntaxes are accepted.

Example attolpreproC gen.ptu code -restriction=ANSI



-rename=

Description This option generate an ATTOL Coverage option file to allow the renaming of thesimulated functions.

Characteristics This option must be used only in a ATTOL UniTest - ATTOL Coverage interface

Default option By default, this file is not generated.

Example attolpreproC gen.ptu code -rename=coverage.opt



-service={,< service name >}

Description This option specifies a list of services to be executed.

Characteristics The ATTOL Test Generator only generates the source code related to these services.

This option and the -exservice option are mutually exclusive.

The names of services are separated by a comma.

If you specify an unknown service in the ATTOL language file, the ATTOL Test Generatordisplays a warning message at the end of execution.

Default option By default, all services are selected.

Example attolpreproC gen.ptu code -service=add_str

Only service add_str is selected

attolpreproC gen code -service=add_str,diff_str

Only services add_str and diff_str are selected



-source=

Description This option tells the ATTOL Test Generator the name of the tested source file.

Characteristics Using this option enables ATTOL to :

9 maintain the source_file name in the table of correspondence file so that the ATTOLReport Generator can display this name in the header of the results obtained file,

9 establish the list of include files in the tested source file.

Default option By default, the list of include files in the tested source file and the source_file name are notdisplayed in the Results Obtained file.

Example attolpreproC gen.ptu code -source="source/mod.c"

The name of the tested source file may be specified with a relative or absolute directory in a syntax recognized bythe operating system, or, in UNIX, by an environment variable.



-strver=

Description This option specifies a identifying string that tells the ATTOL Test Generator to search thesource file, (if it is indicated by the source option, for its version, using the following rule :

The file version is the first word enclosed in quotes (') or double quotes (") after theidentifying string on the same line, where such a word exists, otherwise, it is the first word after the identifying string on the same line.

Characteristics The version is only searched for if the source file is indicated by the -source option.

If this version is found in the file, it replaces the one specified in the HEADER instruction(second parameter).

If the two versions differ, a warning message is displayed.

Default option By default, the version included is the one given in the HEADER instruction.

Example attolpreproC gen code -source="mod.c" -strver=@#



-syscomp=DOS | OS2 | VMS | UNIXDescription The -syscomp option defines the operating system on which the test program generated by

ATTOL will be compiled.

Characteristics This option is used when the test program is compiled on a different machine to the oneexecuting ATTOL;. e.g. generating in UNIX and then compiling and executing in DOS.

-syscomp can take the following four values :

x UNIX for Unix machines

x DOS for PCs running on DOS or Windows

x OS2 for PCs running on OS2

x VMS for Vax/Vms and Alpha/OpenVms machines

Default option The default value of -syscomp is the operating system of the machine on which ATTOL isbeing executed.

Example attolpreproC gen.ptu code -syscomp=DOS



-symbtab=

Description The -symbtab option tells ATTOL to generate a file containing a description of all testabledata in the analyzed test plan.

Characteristics If the symbol table file does not have an extension, ATTOL attaches the extension .smb.

If the file cannot be created, a fatal error is generated.

This symbol table file consists of three parts :

9 a list of global variables and their type,

9 a list of testable functions with their parameters specified by type,

9 a list of structured types described field by field.

Default option By default, a symbol table file is not generated.

Example attolpreproC gen.ptu code -symbtab=fictab



-test={,< test name >}

Description This option specifies a list of tests to be executed.

Characteristics The ATTOL Test Generator only generates the source code related to these tests.

This option and the -extest option are mutually exclusive.

The names of tests are separated by a comma.

If you specify an unknown test in the ATTOL language file, the ATTOL Test Generatordisplays a warning message at the end of execution.

Default option By default, all tests are selected.

Example attolpreproC gen.ptu code -test=5

All tests with name "5" are selected

attolpreproC gen.ptu code -test=1,5

All tests with name "1" or "5" are selected



-version=

Description This option defines the version of the C compiler used.

Characteristics version may take any value. This value will appear in the output report.

Default option By default, the compiler version does not appear in the output report.

Example attolpreproC gen.ptu code -version=1.0 ...



@

Description This syntax allows to pass the options to the pre-processor via a file.

Characteristics The option file name can b

Documents

rmcgb__cel_mai_util.pdf