[Previous] [Next] [Contents] [Index]

    The H2SDL Utility

The H2SDL utility makes it possible to access C code declarations and definitions in SDL. A C code header file is translated into SDL-PR thus making the C code constructs available as if they were declared in SDL.

H2SDL is fully integrated in SDT. It can also be started from a command shell as a stand-alone utility to create SDL-PR packages.

This chapter is the reference manual for the H2SDL utility. The reader is assumed to be familiar with C and SDL/SDT.

Table of Contents 

Introduction

The purpose of H2SDL is to provide a means of making external C functions, typedefs, etc. available inside SDL. H2SDL translates C header files and generates SDL packages.

H2SDL is fully integrated in SDT; the Analyzer starts the tool automatically when it finds a C header file in the Organizer.

H2SDL can also be run in stand-alone mode, i.e. started from a shell command line.

When translating from C to SDL, H2SDL follows a set of translation rules. These rules are described in detail in C to SDL Translation Rules. Although H2SDL supports translation of a major part of the C language, not everything is supported. The limitations of H2SDL are listed in H2SDL.

H2SDL Input and Output

Figure 177 shows the input to and output from H2SDL.

Figure 177  : H2SDL input and output.

Extracted pic [2]

As can be seen in the figure, the input header file is first sent to a C preprocessor. The output from that is one single file, where all preprocessor directives such as #include and #define have been resolved and removed. This file is then translated by H2SDL to an SDL package.

H2SDL can be instructed to use any C preprocessor for preprocessing the header file. If no particular preprocessor is specified, H2SDL assumes a default preprocessor (cpp on UNIX and cl (Microsoft Visual C++) in Windows). It is then required that this default preprocessor is in the path or that there is a link to it in the directory from which H2SDL was started. Here are two examples of directories where cpp might be found:

(You might have another version of gcc, but the above gives you a clue where to look.)

Running H2SDL Stand-Alone

From a shell command line H2SDL is invoked with:

In stand-alone mode all text output, such as error messages, version information etc., is directed to stderr.

If nothing else is specified by options, H2SDL will save the generated SDL package in a file called headername_SDL.pr, where headername is the name of the C header file. The output file will be placed in the same directory as the input file. The name of the SDL package will be untitled if nothing else is specified.

Command-Line Options

The H2SDL command-line options must be set for each input file. Only the -post option differs from this, as described below. H2SDL has the following options:

Example 38 : Running H2SDL stand-alone      

This will generate the file Curses.pr from the file /usr/include/curses.h. The resulting SDL package will be named CursePack and the options -I/include/h -D__STDC__ will be sent to the default C preprocessor.

When the Analyzer Starts H2SDL

When H2SDL is started automatically by the SDT Analyzer, the input are the C headers that are present in the Organizer view. For information on how to include C headers in your SDL system, see Organizing C Headers in SDT.

Each C header in the Organizer is translated to an SDL package according to the procedure depicted in Figure 177. The packages are then included in the finally generated SDL-PR file that is the input to the Analyzer.

Error messages and warnings produced by H2SDL during the translation are output to the Organizer Log.

Setting Options for the Preprocessor and H2SDL

Figure 178 shows the H2SDL Options dialog which is reached from the Organizer's Analyzer dialog. The dialog is used to set options for the preprocessor and for H2SDL.

Options to be passed to the preprocessor are entered in the field labelled Preprocessor options. This makes it for example possible to set include directories and defines for the included files.

Figure 178  : The H2SDL Options dialog

Extracted pic [1]

Example 39 : Setting preprocessor options      

Assume we have the following files and libraries:

The contents of const.h which we want to include in our SDL system is:

To make this work the preprocessor needs the full path to the directory containing theincfile.h. Since we want to use the special type zType we must set the define USE_Z. We open the H2SDL Options dialog, turn on Preprocessor options (see Figure 178), and enter the following:

Consult the manual for your preprocessor to find out how to set include directories and defines.

The other fields and toggle buttons of the H2SDL Options dialog are more or less self-explaining and correspond directly to the command-line options described in Command-Line Options:

References to the Translation Source Files

References to declarations in the source files are on the form: /*#SDTREF(TEXT,relative_path_and_filename,lineno)*/

Where:

In stand-alone mode H2SDL generates source code references if the -r option is used. When the Analyzer starts H2SDL, source code references are always generated.

Error references have the same form as source code references but with a column position added after the line number. H2SDL prints error references when errors (or warnings) are found during translation. They are output to stderr or to the Organizer Log depending upon whether H2SDL is run in stand-alone mode or started automatically by the Analyzer.

A source code reference is shown in Example 40 below.

Example 40 : Source code references      

Problems with error references may arise because of the preprocessor. Among other things, the preprocessor expands macros, and a typical problem is illustrated in Example 41 below.

Example 41        

File def.h, and using H2SDL as a stand-alone tool:

This results in the following error message:

Here the column position (25) is two characters off the target in the original file. When using the Organizer Log's Show Error function (see Show Error) to view the source of this error message, the cursor (?) will be placed at int instead of at the `,'. H2SDL calculates its references from the preprocessed source code where init is expanded to init32. This leads to reference errors like the one described and can make macros a grievance for the H2SDL user in the same way as for many users of C debuggers.

C to SDL Translation Rules

Introduction

H2SDL will translate a C header to SDL for use as a package in SDT. Example 42 below shows such a package. As can be seen, a /*#C `<filename>'*/ directive is inserted directly after the package name. Thereby the Analyzer is told that this is a special package with definitions imported from a C header file. This information is passed on to the C Code Generator to tell it not to generate code for the package. Instead the original header file is included in the generated C code, so in the final executable application it is actually the original C header that is used.

A C header file often includes other header files, and by means of the preprocessor H2SDL will generate code for the entire include tree. This is shown in Example 42 where the file test1.h, which includes test2.h, is translated with H2SDL.

Example 42        

File test1.h:

File test2.h:

Let us now run H2SDL stand-alone on test1.h:

The resulting package untitled includes the definitions from test2.h and is saved to a file called test1_SDL.pr:

New Generators -- CArray and Ref

In order to handle arrays declared in C, two new SDT specific generators have been defined in the package ctypes:

More information about ctypes can be found in Integration with C Data Types.

Basic Type Mapping

The table below describes how basic C types map to SDL sorts. Many types in C have a natural counterpart in SDL, but for some special C types, such as void *, dedicated SDL newtypes have been defined. These definitions can be found in the ctypes package (see Integration with C Data Types.)

Note: 

Some of the SDL sorts listed in the table below (LongLongInt and UnsignedLongLongInt) are not defined in the ctypes package. The reason is that not all C compilers support long long types. You have to write these definitions yourself if you want to use the C types that map to these SDL sorts. Alternatively you may contact Telelogic Support to retrieve an extended version of the ctypes package that contains LongLongInt and UnsignedLongLongInt.

C SDL Comment 
void *
 
VoidStar

SDL sort defined in ctypes.

 
void **
 
VoidStarStar

SDL sort defined in ctypes.

 
signed int
int
 
Integer
 


unsigned int
unsigned
 
UnsignedInt

SDL sort defined in ctypes.

 
signed long int
signed long
long int
long
 
LongInt

SDL sort defined in ctypes.

 
unsigned long int
unsigned long
 
UnsignedLongInt

SDL sort defined in ctypes.

 
signed short int
signed short
short int
short
 
ShortInt

SDL sort defined in ctypes.

 
unsigned short int
unsigned short
 
UnsignedShortInt

SDL sort defined in ctypes.

 
signed long long int
signed long long
long long int
long long
 
LongLongInt

SDL sort not defined in ctypes.

 
unsigned long long int
unsigned long long
 
UnsignedLongLongInt

SDL sort not defined in ctypes.

 
signed char
char
 
Character
 


char *
 
CharStar

SDL sort defined in ctypes.

 
unsigned char
 
Octet
 


float
 
Float

SDL sort defined in ctypes.

 
double
long double
 
Real
 


<type> *
 
ref(<SDLtype>)

SDT Ref generator defined in ctypes.

 
<type>[]
 
ref(<SDLtype>)

SDT Ref generator defined in ctypes.

If the C header has been written exclusively for being combined with SDL, it is sometimes useful to be able to refer to SDL sorts directly from the C code. This can be done by preceding the SDL sort name with "SDL_". For example, the "C type" SDL_PId translates to the SDL sort PId. All predefined SDL types can be accessed this way. See Predefined Sorts for a description of the predefined sorts in SDL.

The C type void is a very special type that has no corresponding sort in SDL. The way H2SDL translates void depends on the context, as shown in Example 43 below .

Example 43  : Translating void      

C header file:

SDL translation:

C Operators and Constant Expressions

The following C operators are handled in expressions: *, /, %, +, -, =

A constant expression can be any valid arithmetic expression consisting of the operators mentioned above, enumerators and integer expressions. Parenthesis, ( and ), are allowed. Only hexadecimal and decimal constants are supported.

Modifying C Identifiers to Conform to SDL

Due to the differences between the C language and SDL it is sometimes not possible to let an identifier in C keep its name when mapped to SDL. There are three reasons behind naming conflicts:

The first case may occur since C is a case sensitive language while SDL is not. These naming conflicts are resolved by adding a unique suffix to names that would be illegal in the SDL namespace. The rule is simple; the first version of a C identifier can keep its name in SDL, the second version is suffixed "_1", the third version is suffixed "_2" and so on. See Example 44.

The second and third case are handled by adding a prefix to the identifier's name in SDL. The rules are:

If a C name that gets modified by H2SDL is to be accessed from SDL, the modified name must be used. The original name is included in the SDL declaration by means of a /*#NAME*/ directive. This directive tells the C Code Generator what name the identifier shall have in the generated C code.

Example 44  : Name modifications due to naming conflicts      

translates to:

If possible, try to avoid using names in the C header that will need to be modified by H2SDL. Names that need to be suffixed because of their capitalization are a particular problem since their names in SDL will depend upon the order in which they first appear in the C header file.

In stand-alone mode H2SDL can be run with the -w option to get warnings for each name modification made by H2SDL. From SDT the same thing is accomplished by opening the H2SDL Options dialog and setting the option Display all warnings on (see Setting Options for the Preprocessor and H2SDL).

General Declaration Mapping

Type Declarations

The table below shows how type declarations in C are translated to SDL. <type> can be substituted for any C type except for void. It can also be a typedef name. <SDLtype> is the translation of <type> as listed in the type translation table in Basic Type Mapping.

C SDL 
typedef <type> T;
 
syntype
  T = <SDLtype>;
endsyntype;
 
typedef <type> *T;
 
newtype T
  ref(<SDLtype>);
endsyntype;
 
typedef <type> T[20];
 
newtype T
  CArray(20,<SDLtype>);
endnewtype;
 
typedef <type> *T[20];
 
newtype Ref_filename_<SDLType> /*#SYNT*/
  ref(<SDLtype>);
endnewtype;

newtype T
  CArray(20,Ref_filename_<SDLtype>);
endnewtype;
 
typedef <type> (*T)(<type>);
 
syntype
  T = VoidStar;
endsyntype;

Note that the SDT generator CArray takes two arguments; an integer for the number of array elements followed by an SDL type.

In the example typedef <type> *T[20]; the array consists of pointers to <type>. In C this kind of compound declarations can be written in a very compact way on one single line. However, the declaration is in fact two declarations in one; a declaration of type T1 that is a pointer to <type>, and a declaration of type T2 that is an array of elements of type T1. The type T1 is called an in-line type. SDL has no in-line types, so for such C declarations H2SDL actually must generate SDL declarations for the in-line types. These declarations are marked with a /*#SYNT*/ directive which informs the C Code Generator that this type has been synthesized by H2SDL.

Synthesized types are named by H2SDL as follows:

Example 45 below is an example of a common situation where H2SDL must create a dummy struct for the in-line declared struct variable aStructVar. The in-line declared struct translated to SDL is named DS_test_0, where test is the name of the file and 0 is a number to make the entire type name unique.

Example 45  : Translating in-line types      

C header test.h:

translates to:

As can be seen in the example, a special synthesize directive called /*#SYNTNN*/ is used for the in-line declared struct type. This directive is used instead of /*#SYNT*/ when the in-line declared type has no complete name (NN = No Name).

Variable Declarations

The following storage class specifiers are supported for variables:

Variables without explicit storage class, e.g. int a;, are also handled.

Except for typedef, all declarations with the supported storage classes will be translated according to the same rule:

C SDL 
extern <type> aVar;
or
static <type> aVar;
or
<type> aVar;
 
procedure Set_aVar;
  fpar setVal <SDLtype>;
external;

procedure Get_aVar;
  returns <SDLtype>;
external;

/*#CODE
#HEADING
#define Set_aVar(i) (aVar=(i))
#define Get_aVar()  (aVar)
*/

<SDLtype> is the translation of <type> as listed in the type translation table in Basic Type Mapping. If <type> is an in-line type, synthesized types will be created as needed. H2SDL automatically creates C #defines to provide a method of accessing the variable. When variable declarations appear in the following sections, the C code part is skipped and only the Get_ and Set_ procedure declarations are shown in order to save space.

Note: 

Be aware that placing non-declarative constructs (definitions) in a C header will most likely lead to link errors when compiling the final code. Thus the variable declaration int a; will be fine, while the variable definition int a = 1; will give a link error.

The reason is that the C header is included in two different modules in the final code. These modules will be separately compiled and then linked together. This is normally not a problem since well-designed C headers should contain nothing but declarations.

Enum Declarations

H2SDL supports two different translation rules for enum declarations. If the -e option is used (see Setting Options for the Preprocessor and H2SDL and Command-Line Options to see how this is done), enum literals will be translated to integer synonyms, and enum types will become syntypes of integer. See Example 46.

Example 46  : Enum translations with the -e option      

translates to:

This translation rule is present for backward compatibility reasons only. It should normally be avoided, since some target compilers give errors due to implicit type conversions from integer to enum that arise when compiling the resulting C code.

Use the default translation rule instead that maps enum declarations to newtypes with literals, as described in the table below.

C SDL 
typedef enum tag {a,b} E;
 
newtype Enum_tag
literals a,b;
/*#ADT()
#TYPE
typedef enum tag #(Enum_tag);
#define #(a) a
#define #(b) b
*/
endnewtype Enum_tag;

syntype
  E = Enum_tag
endsyntype;
 
typedef enum tag E;
 
syntype
  E = Enum_tag
endsyntype;
 
typedef enum {a,b} E;
 
newtype E
literals a,b;
/*#ADT()
#TYPE
#define #(a) a
#define #(b) b
*/
endnewtype E;
 
typedef enum tag {c=10,d=20};
 
newtype Enum_tag
literals c,d;
/*#ADT()
#TYPE
typedef enum tag #(Enum_tag);
#define #(c) c
#define #(d) d
*/
endnewtype Enum_tag;
 
typedef enum {e,f};
 
newtype DE_enumtest_0 /*#SYNT*/
literals e,f;
/*#ADT()
#TYPE
#define #(e) e
#define #(f) f
*/
endnewtype DE_enumtest_0;
 
enum tag {a=1,b=3} var;
 
newtype Enum_tag
literals a,b;
/*#ADT()
#TYPE
typedef enum tag #(Enum_tag);
#define #(a) a
#define #(b) b
*/
endnewtype Enum_tag;

procedure Set_var;
  fpar setVal Enum_tag;
external;

procedure Get_var;
  returns Enum_tag;
external;
 
enum {a,b} var;
 
newtype DE_enumtest_0 /*#SYNT*/
literals a,b;
/*#ADT()
#TYPE
#define #(a) a
#define #(b) b
*/
endnewtype DE_enumtest_0;

procedure Set_var;
  fpar setVal DE_enumtest_0;
external;

procedure Get_var;
  returns DE_enumtest_0;
external;
 
enum tag var;
 
procedure Set_var;
  fpar setVal Enum_tag;
external;

procedure Get_var;
  returns Enum_tag;
external;
 
enum {a=2, b=a*2};
 
newtype DE_enumtest_0 /*#SYNT*/
literals a,b;
/*#ADT()
#TYPE
#define #(a) a
#define #(b) b
*/
endnewtype DE_enumtest_0;

Note that enum tags are prefixed with Enum_ when translated to SDL since SDL has no tag concept like C does.

An enum literal can be set to the value of any constant expression. Currently only hexadecimal and decimal constants are supported.

Struct Declarations

Struct declarations are translated to SDL structs according to the table below. <SDLtype> is the translation of <type> as listed in the type translation table in Basic Type Mapping.

C SDL 
typedef struct Tag{
  <type> a;
} S;
 
/* Global #defines */
/*#CODE
#TYPE
#define #(S)_s Tag
*/

newtype S struct
  a <SDLtype>;
endnewtype S;

syntype Struct_Tag /*#SYNT*/ =
  S
endsyntype;
 
typedef struct Tag{
  <type> a;
};
 
/* Global #defines */
/*#CODE
#TYPE
#define #(Struct_Tag)_s Tag
*/

newtype Struct_Tag struct
  a <SDLtype>;
/*#ADT()
#TYPE
typedef struct Tag #(Struct_Tag);
*/
endnewtype Struct_Tag;
 
typedef struct {
  <type> a;
} S;
 
newtype S struct
 a <SDLtype>;
endnewtype S;
 
typedef struct Tag S;
 
syntype
  S = Struct_Tag
endsyntype;
 
struct Tag{
  <type> a;
} S;
 
/* Global #defines */
/*#CODE
#TYPE
#define #(Struct_Tag)_s Tag
*/

newtype Struct_Tag struct
  a <SDLtype>;
/*#ADT()
#TYPE
typedef struct Tag #(Struct_Tag);
*/
endnewtype Struct_Tag;

procedure Set_S;
  fpar setVal Struct_Tag;
external;

procedure Get_S;
  returns Struct_Tag;
external;
 
struct Tag{
  <type> a;
};
 
/* Global #defines */
/*#CODE
#TYPE
#define #(Struct_Tag)_s Tag
*/

newtype Struct_Tag struct
  a <SDLtype>;
/*#ADT()
#TYPE
typedef struct Tag #(Struct_Tag);
*/
endnewtype Struct_Tag;

Note that struct tags are prefixed with Struct_ when translated to SDL since SDL has no tag concept like C does.

Union Declarations

Union declarations are translated according to the same translation rules as for structs. The only difference is that a /*#UNIONC*/ directive is inserted after the newtype name. This directive informs the C Code Generator that the type corresponds to a proper C union. <SDLtype> is the translation of <type> as listed in the type translation table in Basic Type Mapping.

C SDL 
typedef union Tag{
  <type> a;
} U;
 
/* Global #defines */
/*#CODE
#TYPE
#define #(U)_s Tag
*/

newtype U /*#UNIONC*/ struct
  a <SDLtype>;
endnewtype U;

syntype Union_Tag /*#SYNT*/ =
 U
endsyntype;
 
typedef union Tag{
  <type> a;
};
 
/* Global #defines */
/*#CODE
#TYPE
#define #(Union_Tag)_s Tag
*/

newtype Union_Tag /*#UNIONC*/ struct
  a <SDLtype>;
/*#ADT()
#TYPE
typedef union Tag #(Union_Tag);
*/
endnewtype Union_Tag;
 
typedef union {
  <type> a;
} U;
 
newtype U /*#UNIONC*/ struct
  a <SDLtype>;
endnewtype U;
 
typedef union Tag U;
 
syntype
  U = Union_Tag
endsyntype;
 
union Tag{
  <type> a;
} U;
 
/* Global #defines */
/*#CODE
#TYPE
#define #(Union_Tag)_s Tag
*/

newtype Union_Tag /*#UNIONC*/ struct
  a <SDLtype>;
/*#ADT()
#TYPE
typedef union Tag #(Union_Tag);
*/
endnewtype Union_Tag;

procedure Set_U;
  fpar setVal Union_Tag;
external;

procedure Get_U;
  returns Union_Tag;
external;
 
union Tag{
  <type> a;
};
 
* Global #defines */
/*#CODE
#TYPE
#define #(Union_Tag)_s Tag
*/

newtype Union_Tag /*#UNIONC*/ struct
  a <SDLtype>;
/*#ADT()
#TYPE
typedef union Tag #(Union_Tag);
*/
endnewtype Union_Tag;

Note that union tags are prefixed with Union_ when translated to SDL since SDL has no tag concept like C does.

H2SDL will translate all unions to SDL, but unions containing pointers or bitfields will not be accepted by the C Code Generator. See UnionC for more information.

Bitfield Declarations

A bitfield is a struct or union member consisting of a specified number of bits. The size of a bitfield is set by a constant expression. An example is given in Example 47 below.

Example 47  : Translating bitfields      

translates to:

The bitfields in the generated SDL code are SDT specific and are described in detail in Struct.

Once again note that although H2SDL will generate code for bitfields in unions, the C Code Generator does not support this feature.

Function Declarations

In C two different kinds of function declarations can be used; old-style function declarations and function declarations with prototypes. An old-style function declaration (also known as a Kernighan & Ritchie declaration) is on the form resulttype functionname (); and does not give any information at all about the function's parameters. H2SDL therefore only supports function declarations with prototypes.

Function translation to SDL is not affected by the linkage type of the function. Functions are translated in the same way whether they are declared with external linkage or not. In the table below, <type> can be substituted for any C type, in-line type or typedef type. <SDLtype> is the translation of <type> as listed in the type translation table in Basic Type Mapping.

C SDL 
void func(void);
 
procedure func;
external;
 
<type> func(void);
 
procedure func;
  returns <SDLtype>;
external;
 
<type> func(<type> a, <type> b);
 
procedure func;
  fpar
    a <SDLtype>,
    b <SDLtype>;
  returns <SDLtype>;
external;
 
func(<type> a, <type> b);
 
procedure func;
  fpar
    a <SDLtype>,
    b <SDLtype>;
  returns Integer;
external;
 
<type> func(<type>, <type>);
 
procedure func;
  fpar
    fpar_0 <SDLtype>,
    fpar_1 <SDLtype>;
  returns <SDLtype>;
external;

Note that function parameters without name will be named fpar_x, where x is a number starting on 0 and increasing.

A C function declaration with a varying number of parameters, i.e. its parameter list ends with an ellipsis notation (...), will be translated as shown below.

C SDL 
<type> func(<type> a, ...);
 
procedure func;
  fpar
    a <SDLtype>;
    /*#C_ELLIPSIS*/
  returns <SDLtype>;
external;

The directive /*#C_ELLIPSIS*/ is a place-holder for the ellipsis notation since SDL has no ellipsis concept. Example 48 below suggests how C functions with a varying number of parameters can be used from SDT.

Example 48        

printf(), which is included in stdio.h, is a typical example of a function which can be called with a varying number of arguments of different types. A wrapper file can be used to tailor special versions of printf() to be called from SDT.

File wrap.h:

The resulting SDL file is:

The procedures printf1 and printf2 are now available in SDL. When compiled and linked the calls will be to printf() with one or two integer arguments.

Constant Variable Declarations

Constants are translated to external SDL synonyms. <SDLtype> is the translation of <type> as listed in the type translation table in Basic Type Mapping.

C SDL 
const <type> a = <expression>;
 
synonym a <SDLtype> = external;

Note that constants specified with macros (e.g. #define MIL 1000) will not be translated by H2SDL since they are expanded and removed by the preprocessor before H2SDL sees them. Nevertheless it is possible to access such macro values from SDL by means of the implicit #CODE operator (see Including C Code in SDL Expressions -- Operator #CODE for more information about the #CODE operator). Example 49 below demonstrates how to do this.

Example 49  : Accessing macro values from SDL      

File macrotest.h:

The macro MIL may be accessed from SDL using the #CODE operator:

Naturally, this SDL assignment will be accepted by the Analyzer no matter how MIL actually is defined. Any type problems will not be detected until the generated C code is compiled.

Other techniques for dealing with macros are described in the section When the Built-in Translation Rules Fail.

Error Messages

When H2SDL finds an error it will issue an error message which is sent to the Organizer Log, or to stderr (in stand-alone mode).

Please note that H2SDL will cascade error messages and continue until it finds the end of the file. This can lead to strange results; an error in a struct declaration will probably lead to struct members being declared in an erroneous scope in the translation file.

The listing below explains all errors and warnings that may be issued by H2SDL:

ERROR 3000 Syntax error in declaration

The C code in the header file contains a syntax error.

ERROR 3101 Typedef functions not supported!

An attempt to declare a typedef function was made. Typedef functions are not supported by H2SDL since there is no translation rule for them.

ERROR 3102 Symbol redefined: <name>

A symbol called <name> was redefined. The symbol could be for example an enum literal or a variable.

WARNING 3103 Operator sizeof does not know size of this type

The sizeof() operator is not fully supported by H2SDL; it currently only works for predefined C types. This warning informs that H2SDL has made the assumption that the size of the type is 1.

WARNING 3104 Operator sizeof cannot calculate size of this expression

The sizeof() operator is not fully supported by H2SDL; it currently only works for predefined C types. This warning informs that H2SDL has made the assumption that the size of the expression is 1.

ERROR 3107 Typedef name redefined: <typename>

A typedef name called <typename> was redefined. This means that the C code contains two declarations on the form typedef <typeX> <typename>; where the second of these makes an illegal redefinition of <typename>.

ERROR 3108 Typedef declaration with only one identifier

H2SDL found a declaration on the form typedef <typename>;. The base type is missing.

ERROR 3109 Declaration with keyword struct/union missing

An attempt to declare an aggregate type was made, but the keyword struct or union is missing.

ERROR 3110 Kernighan & Ritchie function declarations not supported

H2SDL does not support old-style function declarations (Kernighan & Ritchie function declarations). Rewrite it using function prototypes.

WARNING 3113 Function pointer will be replaced by VoidStar

H2SDL has found a function pointer type that will be mapped to the SDL type VoidStar. This warning is issued for variables of function pointer type, typedef declarations of a function pointer type, and struct/union declarations with fields of function pointer type. The reason for warning is that the mapping requires that the target compiler is able to do certain implicit type conversions, e.g. from a function pointer to a pointer to void.

WARNING 3114 Symbol <name> is not legal in SDL namespace. Will be named: <SDLname>

This warning informs that H2SDL had to modify <name> to be legal according to SDL naming rules. <name> either was not unique by spelling, was an SDL reserved word, or contained an illegal combination of underscores. The symbol will be renamed to <SDLname>.

WARNING 3115 Possibly illegal redeclaration of identifier: <name>. Declaration ignored.

H2SDL has found a variable or function called <name> that was already declared. This is legal in C if the declarations have exactly the same types. H2SDL does not perform any type checks, but assumes that the redeclaration is legal and simply ignores it. However, a warning is issued to inform that the header file might contain an error.

Common Errors and How to Interpret Them

After finding an error H2SDL is reset and tries to continue the translation. This will in most cases result in a cascade of translation errors and error messages since the proper scope was lost, typedef names were never declared and so on.

A few of the most common errors are discussed in the examples below.

Example 50        

The code segment above results in the following error messages:

The first error message is caused by unknownType which for some reason is undeclared. The second error message is caused by fnPtr never being defined because of the error in the fnPtr typedef declaration. The third error message is caused by the fact that after the second error H2SDL resets its scope level. The `};' is thus considered to be a declaration on its own, and not the end of the struct declaration.

The following is written to the SDL-PR output file:

aVar is translated as if it was a global variable because the struct scope was lost in the second error.

Example 51 below is basically the same problem as Example 50 above.

Example 51        

H2SDL will print the following error messages:

Here unknownType gives rise to error messages which may be hard to understand. The first message is the result of the H2SDL parser treating the unknownType as an identifier. Thus H2SDL thinks it sees two identifiers on line 2, which would not be a valid C statement. In this case it would be easy to interpret the error as if it was caused by the identifier Class.

The second message is issued because the parser is reset after the first error is found. When it continues, a `}' is found which, of course, is not a valid C statement either.

Errors like these will occur when unknownType is undeclared. This, in turn, happens when the declaration of unknownType contains constructs not supported by H2SDL, for example a typedef function. Worth noting is that translation errors inside structs will result in one syntax error for every right curly brace, `}', belonging to the erroneous struct.

[Previous] [Next] [Contents] [Index]