This chapter covers common problems and issues you will encounter when porting a programming project from Microsoft Visual Studio's C/C++ compilers to CodeWarrior. Specifically, this chapter covers differences and potential problems (and solutions) you will encounter when porting a project originally developed for the Win32/x86 platform.
This chapter has these sections:
Notable differences between CodeWarrior C and C++ compilers and the Microsoft C and C++ compilers are listed here:
When the ANSI Strict option in the C/C++ Language settings panel is enabled, all non-standard language extensions
are disabled. Unless you are writing software that must be portable
to any ANSI C/C++ platform, you probably should leave ANSI Strict
option turned off.
Refer to the C Compilers Reference for complete information on
the ANSI Strict option.
These language extensions include:
typedefs
void return type for main()
int-sized
asm()-form inline assembly
//")
long long constants with "i64" suffix
d" suffix
0b" prefix
# on line by itself
#else and #endif
#warning and #ident preprocessor directives
When you turn on the Relaxed Pointer Type Rules option in the C/C++ Language settings panel, CodeWarrior C overlooks the normal type checking
it does when assigning from one pointer to another. The compiler
does not warn or give an error message in cases where you mix
pointers to different types. For example, when this option is
on, the compiler will allow code like this:
struct foo *mary; char *bob = mary;
This option should be avoided when possible.
This option has no effect on C++. When compiling C++ source code, the compiler differentiates pointer types even if this option is on.
This option exists to make it easier to port old pre-ANSI C code
that assumed that any pointer had the same representation as any
other pointer. C source code for Microsoft Windows that uses generic
handles (HANDLE) instead of specific types of handles (for example, HWND) might not compile with this option turned off.
CodeWarrior currently does not support Microsoft-compatible C++
runtime type information (RTTI). CodeWarrior does support ANSI/ISO
C++ RTTI, but you cannot use typeof() or dynamic_cast<> on objects compiled by Microsoft C++.
CodeWarrior provides full support for Microsoft-compatible C++ exception handling.
CodeWarrior C++'s name mangling on templates is incompatible with
Microsoft C++'s mangling when ARM Conformance is turned off in the C/C++ Language settings panel. With ARM Conformance off, CodeWarrior can support the differentiation between template
and non-template functions that do not include the template type
in their parameter lists.
template <class T> void foo (int a); void foo (int a);
Using the Microsoft name mangling scheme, these two functions are mangled identically, although, in your code, you could differentiate them by:
CodeWarrior C/C++ follows the IEEE standards regarding the outcome
of comparison operators and NaN (not a number). These are all considered unordered, so any comparison
involving NaN will be false, except for the not equals comparison (!=) which
returns true.
Microsoft C++ version 5 and Microsoft C++ version 6 do not generate
instructions to check the unordered flag on comparisons, so the
result of the comparison may vary depending on the exact encoding
of the NaNs involved in the operation.
CodeWarrior C/C++ compilers for x86 and Microsoft C++ correctly
handle propagation of NaNs through arithmetic operations, as that is handled by the floating
point processor. For any operation, if one or both of the operands
is a NaN, the result will also be a NaN.
If you have problems with this discrepancy in your code, you may
want to enable the processor exception on NaN generation, but most code should never have to deal with these
values.
To do so, you can add this code fragment to your project, with
a call to enable_nan_exception() sometime before you expect the NaN to be generated. You should then enable the Float Invalid Op exception in the x86 Exception debugging settings panel.
#include <fenv.h> void enable_nan_exception(void)
{
fenv_t fe;
// this should turn on exceptions
// on NaN generation
fegetenv(&fe);
fe = fe & ~FE_INVALID;
fesetenv(&fe);
}
Microsoft uses a syntax for the inline assembler in their C/C++ compiler similar to, but not exactly like MASM. Since this is barely documented, the CodeWarrior assembler attempts to duplicate the observed behavior of the Microsoft assembler. Note that there may be some cases where it will not detect an error.
Some of the inline assembler support includes:
EVEN.
SIZE keyword in assembly expressions for getting the size (in bytes)
of an object. CodeWarrior does not support LENGTH or TYPE.
ALIGN, DB, DW, and DD directives. CodeWarrior supports EMIT rather than _emit for directly inserting bytes into the assembly code.
SHORT modifier on jump instructions because it generates short jumps,
if possible, by default. Microsoft uses SHORT as a flag to generate a short jump if possible.
mov dword ptr [foo], eax
mov [foo], eax
as the second form may generate the wrong instruction. This has been fixed in later versions of the assembler.
The CodeWarrior assembler does not accept suffix notation hexadecimal
numbers. 0x1AE3 is allowed, but 1AE3h is not.
The extras.c file (part of MSL for Intel platforms) defines the following functions which are equivalent to functions by the same name in Microsoft's library. These functions include:
CodeWarrior also supports many of the C9X standard's new floating
point functions. In some cases, there are C9X equivalents for
Microsoft library functions, although their interfaces may not
be the same. The MS FPU control functions _clear87(), _clearfp(), _control87(), _controlfp(), _status87(), _fpreset(), and _fpieee_ flt() are supported by functions declared in the C9X fenv.h header
file. CodeWarrior does not implement equivalents of _chgsign() and the Bessel functions.
Some of the functions supported are listed in Table 3.1.
Microsoft functions and their ANSI/ISO equivalents
This Microsoft function
is equivalent to this ANSI/ISO C9X function
: