Commit 250a6da

`_Use_decl_annotations_` tells the compiler to use the annotations from an earlier declaration of the function. If no earlier declaration can be found, or if the current declaration makes changes to the annotations, then this warning is emitted. `_Use_decl_annotations_` also lets you remove all other annotations from the definition, and uses the declaration annotations for analysis of the function.

This diagnostic is frequently a side effect of refactoring or fixing other warnings by adjusting the annotations on a function. To fix the issue, use the same annotations at the other locations. To determine the correct set of annotations, look at the behavior in the function definition. In most cases, this behavior is intentional and should be reflected in the annotations to the function. For more information on SAL annotations, see [Using SAL Annotations to reduce code defects](using-sal-annotations-to-reduce-c-cpp-code-defects.md).

It's important for the annotations to match between the declarations and the definition of a function. When the analysis tools analyze the call site of the function, the declaration annotations are used. If the declaration and definition don't match, the static analysis tools may produce incorrect results. When you fix this warning, it's common for your changes to have cascading effects as the tool reanalyzes the source with updated information.

If this diagnostic occurs because no previous declaration was found in the translation unit, the most likely cause is a missing `#include` directive. To resolve this issue when the header file is intentionally not included, verify that the annotations in the declaration and definition match, and remove the `_Use_decl_annotations_` annotation. Be careful when you don't include a header file, as the two sets of annotations may get out of sync in the future.

Examine the function definition to determine what the correct annotations should be. In this case, `_Out_writes_z_(n)` appears to be correct so we move that annotation to the function declaration in the header file. This resolves the issue because the annotations in the declaration and definition now match.

This warning indicates a function that takes a buffer and a size is passed an unchecked size. The data read-in from some external source hasn't been verified to see whether it's smaller than the buffer size. An attacker might intentionally specify a value far larger than expected for the size, which can lead to a buffer overrun. Generally, whenever you read data from an untrusted external source, make sure to verify it for validity. It's appropriate to verify the size to make sure it's in the expected range.

The following code generates this warning by calling the annotated function `std::fread` two times. The first call is used to determine the length of the data to read in later calls. After the first call, analysis marks `dataSize` as coming from an untrusted source. Therefore, passing the untrusted value to the second `std::fread` call generates this warning. A malicious actor would be able to modify the file and cause the call to `std::fread` to overflow the `buffer` array. In real world code, you should also handle error recovery based on the return value of `std::fread`. For simplicity, error recovery is intentionally left out of these examples.

In `std:fread` and similar functions, the code may need to read large amounts of data. To handle large data, you can allocate the size of the buffer dynamically after the size becomes known. Or, you can call `std:fread` multiple times as needed to read in the rest of the data. If you allocate the buffer dynamically, consider limiting the size to avoid introducing an out-of-memory exploit for large values. We don't use this approach in our example because it's already bounded by the size of `uint8_t`.

This warning indicates that not enough arguments are provided to match a format string and one of the missing arguments is an integer.

The following code generates this warning because an incorrect number of arguments were used in the call to `sprintf_s` and the missing argument was an integer. If the unsafe function `sprintf` was used instead of the safer variant `sprintf_s`, this code would likely cause a stack overflow instead of just an unexpected output:

The purpose of this warning is to avoid the use of uninitialized values by callers of the function. The analyzer assumes all parameters annotated with `_Out_` are uninitialized before the function call, and checks that they're initialized by it. This warning isn't emitted if the function returns a value indicating it had an error or wasn't successful. To fix this issue, make sure the `_Out_` parameter is initialized under all successful return paths. The error message contains the line numbers of an example path that doesn't initialize the parameter.

If the initialization behavior is by design, then the warning is likely caused by incorrect or missing SAL annotations. You can typically resolve these cases by either changing `_Out_` to a more appropriate annotation, or by using the `_Success_()` annotation to help define the success/error states of the function. Having correct annotations on the function is important for the static analysis tools when analyzing the call sites of the function.

If the parameter is expected to 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).

This diagnostic is only emitted when the `_Out_` parameter isn't initialized in the success paths of the function. If there's no `_Success_` annotation and the return type for the function isn't annotated, then all return paths are considered successful. For more information on `_Success_` and similar annotations, see [Success/Failure annotations](./annotating-function-behavior.md#successfailure-annotations).

The following code generates this warning. Because the function returns void, all paths are considered successful. In this case, the correct fix would probably be to adjust the logic of the `if` statement, but in real world code it's typically not as straightforward and depends on the intended behavior of the function.