WINSCW-specific errors and warnings

#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.