Fields of OPTIONS19 are missing _Out_ SAL annotation

[clandrew]

For fields other than ComputeOnlyCustomHeapSupported.

typedef struct D3D12_FEATURE_DATA_D3D12_OPTIONS19
    {
    BOOL MismatchingOutputDimensionsSupported;
    UINT SupportedSampleCountsWithNoOutputs;
    BOOL PointSamplingAddressesNeverRoundUp;
    BOOL RasterizerDesc2Supported;
    BOOL NarrowQuadrilateralLinesSupported;
    BOOL AnisoFilterWithPointMipSupported;
    UINT MaxSamplerDescriptorHeapSize;
    UINT MaxSamplerDescriptorHeapSizeWithStaticSamplers;
    UINT MaxViewDescriptorHeapSize;
    _Out_  BOOL ComputeOnlyCustomHeapSupported;
    } 	D3D12_FEATURE_DATA_D3D12_OPTIONS19;

Technically Out is not valid SAL for struct fields but the header so far has been using them. They can help document what does what.

Link: here

[billkris-ms]

The in/out semantics of struct members really depend on the context in which the struct is used. Different functions may read or write to the same member, and in practice, nearly every member is written at some point (even if only by a constructor).

Applying _In_ or _Out_ SAL annotations directly to struct members can lead to misleading assumptions and may eventually trigger issues with static analysis tools. In truth, the actual problem is that these semantics don’t belong on struct members at all.

The real goal here is to help developers quickly identify which members must be initialized before calling CheckFeatureSupport and which members are populated by CheckFeatureSupport. SAL annotations only make sense if they are scoped specifically to that function, and for that purpose, comments are probably a better choice than SAL.

[clandrew]

Up to you. Whatever you do, it would be nice if the header is consistent

[billkris-ms]

Totally agree. Thanks Claire for pointing this out.