acrolinx

Author: TylerMSFT

docs/c-runtime-library/reference/resetstkoflw.md

@@ -29,9 +29,9 @@ Nonzero if the function succeeds, zero if it fails.
 
 ## Remarks
 
-The **`_resetstkoflw`** function recovers from a stack overflow condition, allowing a program to continue instead of failing with a fatal exception error. If the **`_resetstkoflw`** function is not called, there are no guard pages after the previous exception. The next time that there is a stack overflow, there are no exceptions at all and the process terminates without warning.
+The **`_resetstkoflw`** function recovers from a stack overflow condition, allowing a program to continue instead of failing with a fatal exception error. If the **`_resetstkoflw`** function isn't called, there are no guard pages after the previous exception. The next time that there's a stack overflow, there are no exceptions at all and the process terminates without warning.
 
-If a thread in an application causes an **`EXCEPTION_STACK_OVERFLOW`** exception, the thread has left its stack in a damaged state. This is in contrast to other exceptions such as **`EXCEPTION_ACCESS_VIOLATION`** or **`EXCEPTION_INT_DIVIDE_BY_ZERO`**, where the stack is not damaged. The stack is set to an arbitrarily small value when the program is first loaded. The stack then grows on demand to meet the needs of the thread. This is implemented by placing a page with PAGE_GUARD access at the end of the current stack. For more information, see [Creating Guard Pages](/windows/win32/Memory/creating-guard-pages).
+If a thread in an application causes an **`EXCEPTION_STACK_OVERFLOW`** exception, the thread has left its stack in a damaged state. This is in contrast to other exceptions such as **`EXCEPTION_ACCESS_VIOLATION`** or **`EXCEPTION_INT_DIVIDE_BY_ZERO`**, where the stack isn't damaged. The stack is set to an arbitrarily small value when the program is first loaded. The stack then grows on demand to meet the needs of the thread. This is implemented by placing a page with PAGE_GUARD access at the end of the current stack. For more information, see [Creating Guard Pages](/windows/win32/Memory/creating-guard-pages).
 
 When the code causes the stack pointer to point to an address on this page, an exception occurs and the system does the following three things:
 
@@ -41,7 +41,7 @@ When the code causes the stack pointer to point to an address on this page, an e
 
 - Reruns the instruction that raised the exception.
 
-In this way, the system can increase the size of the stack for the thread automatically. Each thread in a process has a maximum stack size. The stack size is set at compile time by the [`/STACK` (Stack Allocations)](../../build/reference/stack-stack-allocations.md), or by the [`STACKSIZE`](../../build/reference/stacksize.md) statement in the .def file for the project.
+In this way, the system can increase the size of the stack for the thread automatically. Each thread in a process has a maximum stack size. The stack size is set at compile time by the [`/STACK` (Stack Allocations)](../../build/reference/stack-stack-allocations.md), or by the [`STACKSIZE`](../../build/reference/stacksize.md) statement in the `.def` file for the project.
 
 When this maximum stack size is exceeded, the system does the following three things:
 
@@ -51,9 +51,9 @@ When this maximum stack size is exceeded, the system does the following three th
 
 - Raises an exception so that the thread can handle it in the exception block.
 
-Note that, at that point, the stack no longer has a guard page. The next time that the program grows the stack all the way to the end, where there should be a guard page, the program writes beyond the end of the stack and causes an access violation.
+At that point, the stack no longer has a guard page. The next time that the program grows the stack all the way to the end, where there should be a guard page, the program writes beyond the end of the stack and causes an access violation.
 
-Call **`_resetstkoflw`** to restore the guard page whenever recovery is done after a stack overflow exception. This function can be called from inside the main body of an **`__except`** block or outside an **`__except`** block. However, there are some restrictions on when it should be used. **`_resetstkoflw`** should never be called from:
+Call **`_resetstkoflw`** to restore the guard page whenever recovery is done after a stack overflow exception. This function can be called from inside the main body of an **`__except`** block or outside an **`__except`** block. However, there are some restrictions on when it should be used. **`_resetstkoflw`** shouldn't be called from:
 
 - A filter expression.
 
@@ -65,15 +65,15 @@ Call **`_resetstkoflw`** to restore the guard page whenever recovery is done aft
 
 - A **`__finally`** block.
 
-At these points, the stack is not yet sufficiently unwound.
+At these points, the stack isn't yet sufficiently unwound.
 
-Stack overflow exceptions are generated as structured exceptions, not C++ exceptions, so **`_resetstkoflw`** is not useful in an ordinary **`catch`** block because it will not catch a stack overflow exception. However, if [`_set_se_translator`](set-se-translator.md) is used to implement a structured exception translator that throws C++ exceptions (as in the second example), a stack overflow exception results in a C++ exception that can be handled by a C++ catch block.
+Stack overflow exceptions are generated as structured exceptions, not C++ exceptions, so **`_resetstkoflw`** isn't useful in an ordinary **`catch`** block because it won't catch a stack overflow exception. However, if [`_set_se_translator`](set-se-translator.md) is used to implement a structured exception translator that throws C++ exceptions (as in the second example), a stack overflow exception results in a C++ exception that can be handled by a C++ catch block.
 
-It is not safe to call **`_resetstkoflw`** in a C++ catch block that is reached from an exception thrown by the structured exception translator function. In this case, the stack space is not freed and the stack pointer is not reset until outside the catch block, even though destructors have been called for any destructible objects before the catch block. This function should not be called until the stack space is freed and the stack pointer has been reset. Therefore, it should be called only after exiting the catch block. As little stack space as possible should be used in the catch block because a stack overflow that occurs in the catch block that is itself attempting to recover from a previous stack overflow is not recoverable and can cause the program to stop responding as the overflow in the catch block triggers an exception that itself is handled by the same catch block.
+It isn't safe to call **`_resetstkoflw`** in a C++ catch block that is reached from an exception thrown by the structured exception translator function. In this case, the stack space isn't freed and the stack pointer isn't reset until outside the catch block, even though destructors have been called for any destructible objects before the catch block. This function shouldn't be called until the stack space is freed and the stack pointer has been reset. Therefore, it should be called only after exiting the catch block. As little stack space as possible should be used in the catch block because a stack overflow that occurs in the catch block that is itself attempting to recover from a previous stack overflow isn't recoverable and can cause the program to stop responding as the overflow in the catch block triggers an exception that itself is handled by the same catch block.
 
-There are situations where **`_resetstkoflw`** can fail even if used in a correct location, such as within an **`__except`** block. If, even after unwinding the stack, there is still not enough stack space left to execute **`_resetstkoflw`** without writing into the last page of the stack, **`_resetstkoflw`** fails to reset the last page of the stack as the guard page and returns 0, indicating failure. Therefore, safe usage of this function should include checking the return value instead of assuming that the stack is safe to use.
+There are situations where **`_resetstkoflw`** can fail even if used in a correct location, such as within an **`__except`** block. If, even after unwinding the stack, there's still not enough stack space left to execute **`_resetstkoflw`** without writing into the last page of the stack, **`_resetstkoflw`** fails to reset the last page of the stack as the guard page and returns 0, indicating failure. Safe usage of this function should include checking the return value instead of assuming that the stack is safe to use.
 
-Structured exception handling will not catch a **`STATUS_STACK_OVERFLOW`** exception when the application is compiled with **`/clr`** (see [`/clr `(Common Language Runtime Compilation)](../../build/reference/clr-common-language-runtime-compilation.md)).
+Structured exception handling won't catch a **`STATUS_STACK_OVERFLOW`** exception when the application is compiled with **`/clr`** (see [`/clr `(Common Language Runtime Compilation)](../../build/reference/clr-common-language-runtime-compilation.md)).
 
 By default, this function's global state is scoped to the application. To change this, see [Global state in the CRT](../global-state.md).
 
@@ -115,7 +115,7 @@ int stack_overflow_exception_filter(int exception_code)
    if (exception_code == EXCEPTION_STACK_OVERFLOW)
    {
        // Do not call _resetstkoflw here, because
-       // at this point, the stack is not yet unwound.
+       // at this point, the stack isn't yet unwound.
        // Instead, signal that the handler (the __except block)
        // is to be executed.
        return EXCEPTION_EXECUTE_HANDLER;

docs/c-runtime-library/reference/setjmp.md

@@ -29,19 +29,19 @@ Variable in which environment is stored.
 
 ## Return Value
 
-Returns 0 after saving the stack environment. If **`setjmp`** returns as a result of a `longjmp` call, it returns the *value* argument of `longjmp`, or if the *value* argument of `longjmp` is 0, **`setjmp`** returns 1. There's no error return.
+Returns 0 after saving the stack environment. If **`setjmp`** returns because of a `longjmp` call, it returns the *value* argument of `longjmp`, or if the *value* argument of `longjmp` is 0, **`setjmp`** returns 1. There's no error return.
 
 ## Remarks
 
-The **`setjmp`** function saves a stack environment, which you can subsequently restore, using `longjmp`. When used together, **`setjmp`** and `longjmp` provide a way to execute a non-local **`goto`**. They are typically used to pass execution control to error-handling or recovery code in a previously called routine without using the normal calling or return conventions.
+The **`setjmp`** function saves a stack environment, which you can subsequently restore, using `longjmp`. When used together, **`setjmp`** and `longjmp` provide a way to execute a non-local **`goto`**. They're typically used to pass execution control to error-handling or recovery code in a previously called routine without using the normal calling or return conventions.
 
-A call to **`setjmp`** saves the current stack environment in *env*. A subsequent call to `longjmp` restores the saved environment and returns control to the point just after the corresponding **`setjmp`** call. All variables (except register variables) accessible to the routine receiving control contain the values they had when `longjmp` was called.
+A call to **`setjmp`** saves the current stack environment in *`env`*. A subsequent call to `longjmp` restores the saved environment and returns control to the point just after the corresponding **`setjmp`** call. All variables (except register variables) accessible to the routine receiving control contain the values they had when `longjmp` was called.
 
-It is not possible to use **`setjmp`** to jump from native to managed code.
+It isn't possible to use **`setjmp`** to jump from native to managed code.
 
 **Microsoft Specific**
 
-In Microsoft C++ code on Windows, **`longjmp`** uses the same stack-unwinding semantics as exception-handling code. It is safe to use in the same places that C++ exceptions can be raised. However, this usage is not portable, and comes with some important caveats. For details, see [`longjmp`](longjmp.md).
+In Microsoft C++ code on Windows, **`longjmp`** uses the same stack-unwinding semantics as exception-handling code. It is safe to use in the same places that C++ exceptions can be raised. However, this usage isn't portable, and comes with some important caveats. For details, see [`longjmp`](longjmp.md).
 
 **END Microsoft Specific**
 
@@ -57,7 +57,7 @@ For more information, see [Using `setjmp` and `longjmp`](../../cpp/using-setjmp-
 |-------------|---------------------|
 |**`setjmp`**|\<setjmp.h>|
 
-For additional compatibility information, see [Compatibility](../../c-runtime-library/compatibility.md).
+For more compatibility information, see [Compatibility](../../c-runtime-library/compatibility.md).
 
 ## Example
 

docs/c-runtime-library/reference/wctype.md

@@ -28,7 +28,7 @@ Property string.
 
 ## Return Value
 
-If the **`LC_CTYPE`** category of the current locale does not define a classification rule whose name matches the property string *`property`*, the function returns zero. Otherwise, it returns a nonzero value suitable for use as the second argument to a subsequent call to [`towctrans`](towctrans.md).
+If the **`LC_CTYPE`** category of the current locale doesn't define a classification rule whose name matches the property string *`property`*, the function returns zero. Otherwise, it returns a nonzero value suitable for use as the second argument to a subsequent call to [`towctrans`](towctrans.md).
 
 ## Remarks