RomandevJavaScript
diff --git a/‎docs/code-quality/c26441.md‎
Lines changed: 1 addition & 1 deletion b/‎docs/code-quality/c26441.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎docs/code-quality/c6101.md‎
Lines changed: 1 addition & 1 deletion b/‎docs/code-quality/c6101.md‎
Lines changed: 1 addition & 1 deletion
@@ -19,7 +19,7 @@ The standard library provides locks to help control concurrent access to resourc
 
 This diagnostic only analyzes the standard lock types `std::scoped_lock`, `std::unique_lock`, and `std::lock_guard`. Warning [C26444](c26444.md) covers other unnamed RAII types.
 
-The analyzer only analyzes simple calls to constructors. More complex initializer expressions may lead to missed warnings. For example, the analyzer can't tell whether a temporary guard used as a function call argument deliberately only protects that function call or is a mistake by the user. The analyzer ignores locks passed as arguments to function calls or returned as results of function calls. To provide similar protection for types returned by a function call, annotate them with `[[nodiscard]]`. The analyzer also ignores locks created as temporaries but assigned to named references to extend their lifetime.
+The analyzer only analyzes simple calls to constructors. More complex initializer expressions may lead to inaccurate results in the form of missed warnings. Locks passed as arguments to function calls or returned as results of function calls are ignored because the analysis tool is unable to determine if those locks are deliberately trying to protect that function call or if they should be extended. To provide similar protection for types returned by a function call, annotate them with `[[nodiscard]]`. The analyzer ignores locks created as temporaries but assigned to named references to extend their lifetime.
 
 Code analysis name: `NO_UNNAMED_GUARDS`
 
 
@@ -19,7 +19,7 @@ If the initialization behavior is by design, then incorrect or missing SAL annot
 
 ### Fix by changes to parameter annotations
 
-If the parameter should already be in an initialized state and the function conditionally modifies it, then the `_Inout_` annotation may be more appropriate. Another option is to use lower level annotations such as `_Pre_null_`, `_Pre_satisfies_()`, and `_Post_satisfies_()` that provide extra flexibility and control over the expected state of the parameter. For more information on parameter annotations, see [Annotating function parameters and return values](./annotating-function-parameters-and-return-values.md).
+If the parameter should already be in an initialized state and the function conditionally modifies it, then the `_Inout_` annotation may be more appropriate. If no other high level annotation fits the intended behavior, you can use low level annotationx such as `_Pre_null_`, `_Pre_satisfies_()`, and `_Post_satisfies_()` that provide extra flexibility and control over the expected state of the parameter. For more information on parameter annotations, see [Annotating function parameters and return values](./annotating-function-parameters-and-return-values.md).
 
 ### Fix by defining successful return paths