Export (0) Print
Expand All
Expand Minimize
This topic has not yet been rated - Rate this topic

/RTC - Run-Time Error Checks (Windows CE 5.0)

Windows CE 5.0
Send Feedback

This option enables run-time error checks.

/RTC1
/RTCc
/RTCs
/RTCu

Remarks

The /RTC option is supported by x86 microprocessors only.

The run-time error checks feature is enabled and disabled by the /RTC group of compiler options and the runtime_checks pragma.

OptionDescription
/RTC1Is equivalent to /RTCsu.
/RTCcReports when a value is assigned to a smaller data type that results in a data loss. For example, if a value of type short 0x101 is assigned to a variable of type char.

This option reports situations where you intend to truncate, as in a situation where you want the first eight bits of an int returned as a char.

Because /RTCc causes a run-time error if information will be lost as a result of the assignment, you can mask off the information you need to avoid a run-time error as a result of /RTCc. For example:

#include <crtdbg.h>

char get8bits(int value, int position)
{
_ASSERT(position < 32);
return (char)(value >> position);
// try the following line instead
// return (char)((value >> position) && 0xff);
}

int main()
{
get8bits(12341235,3);
}

/RTCsEnables stack frame run-time error checking:
  • Initialization of local variables to a nonzero value. This helps identify bugs that do not appear when running in debug mode.

    There is a greater chance that stack variables will still be zero in a debug build compared to a release build because of compiler optimizations of stack variables in a release build.

    After a program uses an area of its stack, it is not reset to 0 by the compiler. Therefore, subsequent, uninitialized stack variables that use the same stack area can return values left over from the prior use of this stack memory.

  • Detection of overruns and underruns of local variables such as arrays. /RTCs will not detect overruns when accessing memory that results from compiler padding within a structure.

    Padding could occur by using align, /Zp - Pack Structure Members, or the pack pragma, or if you order structure elements in such a way as to require the compiler to add padding.

  • Stack pointer verification, which detects stack pointer corruption. Stack pointer corruption can be caused by a calling convention mismatch. For example, using a function pointer, you call a function in a DLL that is exported as __stdcall but you declare the pointer to the function as __cdecl.
/RTCuReports when a variable is used without having been initialized. For example, an instruction that generates Compiler Warning C4701 may also generate a run-time error under /RTCu. Any instruction that generates Compiler Warning C4700 will generate a run-time error under /RTCu.
However, consider the following code fragment:

int a, *b, c;
if ( 1 )
b = &a;
c = a; // no run-time error with /RTCu

If a variable could have been initialized, it will not be reported at run time by /RTCu. For example, after a variable is aliased through a pointer, the compiler will not track the variable and report uninitialized uses. In effect, you can initialize a variable by taking its address. The & operator works like an assignment operator in this situation.

Note   If you compile your program at the command line using any of the /RTC compiler options, any pragma optimize instructions in your code will silently fail. This is because run-time error checks are not valid in a release (optimized) build.

The __MSVC_RUNTIME_CHECKS preprocessor directive will be defined when you use any /RTC option or /GZ - Catch Release Errors in Debug Build.

See Also

Compiler Options


Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.


Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.