WINSCW-specific errors and warnings

When you compile code for the WINSCW target, you may get errors and warnings that were not present when building for WINS or ARM targets. This page explains some possible causes of this.

#pragma for disabling warnings

Issue: CodeWarrior compiler ignores the #pragma - warning(...) statements that are used to disable specific Microsoft VC++ warnings.

Resolution: consult the CodeWarrior manuals for equivalent CodeWarrior #pragma controls over specific warnings.

Expression evaluation order

The C++ Standard explicitly states that the order of evaluation of expressions is undefined. For example, for the line,

x = fn1(param1) + fn2(param2);

some compilers may evaluate fn1(param1) first, while others may evaluate fn2(param2) first. Symbian have in fact found cases where CodeWarrior, and Microsoft VC++ and GCC, differ in this behaviour. You should therefore never assume a particular order of evaluation. Note that this error may be hard to find, as program behaviour can be altered, but no compiler warnings are given.

friend statements

Issue: illegal 'friend' declaration compiler errors for statements of the form friend MyClass;.

Resolution: use the syntax friend class - MyClass;.

Identifier names not, or, and, etc.

Issue: compiler errors when using identifiers with the names not, or, and, bitor, xor, compl, bitand, and_eq, xor_eq, or_eq, or not_eq.

This is because these are C++ keywords (alternative token representations for some operators and punctuators).

Resolution: modify the identifier name.

illegal empty declaration warnings

Issue: warnings caused by unneeded semi-colons, for example,

class CMyClass - { -public:;

Resolution: remove unneeded semi-colons.

Inline assembler hex constants

Issue: compiler errors for inline assembler hex constants specified with a trailing h, for example, 0001ah.

Resolution: specify such constants using the C++ 0xnnnn notation.

Inline assembler labels

Issue: compiler errors for assembler labels of the form _asm label:.

Resolution: use C++ labels.

Member functions that include the class name

Issue: illegal access/using declaration compiler errors for class member functions whose declarations include the class name, for example:

class CMyClass - { - void CMyClass::MyFunction(); - };

Resolution: remove the class name from the function declaration.

Mismatched char* and unsigned char* in .c files

Issue: illegal implicit conversion from 'unsigned - char*' to 'const char*' compiler errors when attempting to pass an unsigned char* where a const char* is required.

CodeWarrior marks this as an error for both .c files and .cpp files; MS Visual C++ only marks it as an error for .cpp files.

Resolution: change the declaration or call to use matching types. Alternatively, to tell CodeWarrior not to warn on this issue, use the directive:

#pragma mpwc_relax on

possible unwanted ';' warnings

Issue: this warns you that a loop has no body, for example, as in the following:

for (TInt i=0; i<10; i++); // loop ends here - f(i);

Resolution: if a loop has no body intentionally, the warning can be removed by adding an empty body, for example,

while (f) {};

References to enumerated values declared later

Issue: undefined identifier compiler errors for usage such as

class CMyClass - { - void MyFunction(TInt a=EMyVal1); // EMyVal1 not yet defined - enum - { - EMyVal1 - }; - };

Resolution: move the enumerator's declaration to before its first usage.

References to pointers to const objects

Issue: non-const '&' reference initialized to - temporary compiler errors for use of a reference to a pointer to a non-const object, where a reference to a pointer to a const object is required, for example:

void f(const TInt64*& aNum); - -void f1() - { - TInt64* ptr; - f(ptr); - }

Resolution: the compiler correctly cannot add const-ness at this level of indirection, as the aNum value could then be modified through the ptr pointer. Modify the code to conform with the const-ness rules.

Reuse of variables declared in for

Issue: CodeWarrior follows the C++ standard in limiting the lifetime of a variable declared in a for statement to the loop block. The following code thus gives an undefined identifier error for the use of i in the second for statement.

for (TInt i=0; i<10; i++) - { - ... - } -for (i=0; i<20; i++) - { - ...

Resolution: as Microsoft Visual C++ gives an error if, in the above case, i were to be redeclared in the second for statement. To be compatible with both compilers, declare the loop variable outside the for loop.

sizeof(<non-static class member>) not in the context of an object of that class

Issue: illegal use of non-static member warning for such code as:

class CMyClass - { -public: - int iNonStaticMember; - }; - -int main() - { - printf("%d\n", sizeof(CMyClass::iNonStaticMember)); - }

The error is produced because CMyClass::iNonStaticMember is not the name of a type, nor an expression.

Resolution: a possible resolution is to provide a dummy object to produce a valid expression: for example,

sizeof(((CMyClass*)0)->iStaticMember)

Uninitialised variable warnings

Issue: extra warnings of the form variable - 'myvariable' is not initialized before being used.

Resolution: the warnings are correct, and the code should be corrected.

USER 42 panics when allocating and deleting arrays

Issue: the program panics with USER 42 when allocating and deleting arrays.

Resolution: see Cleanup for heap arrays for details of code techniques to prevent such panics.

Single process and memory protection

The S in WINS and WINSCW stands for "single process". WINS/WINSCW supports multiple threads, but only a single process. This causes slight differences between WINS/WINSCW and target machines.

As WINS/WINSCW only has a single process, each process has access to each other’s memory. This means that bad pointers may corrupt another process’s memory, resulting in bugs which would not occur on a multi-process Symbian platform implementation. Also, design bugs such as using pointers across processes do not show until code is first run on a multi-process platform.