DirectX-Headers icon indicating copy to clipboard operation
DirectX-Headers copied to clipboard

Use of CD3DX12_CPU_DESCRIPTOR_HANDLE in an array can result in static analysis warning

Open EpicChrisWaters opened this issue 3 years ago • 6 comments

Please see this godbolt output https://godbolt.org/z/ozYG6e

If you create an uninitialized array of CD3DX12_CPU_DESCRIPTOR_HANDLE and then initializing the array in a loop with objects of type D3D12_CPU_DESCRIPTOR_HANDLE, it results in a static analysis error on the usage of the uninitialized array. This does not happen with a non-array.

It actually looks like changing just the custom assignment operator can fix this, if you "= default" the "=" operator, the warning goes away. For context, this warning looks like it was introduced when all the constructors were changed from "{}" (empty implementations) to "= default".

EpicChrisWaters avatar Mar 19 '21 19:03 EpicChrisWaters

Since these assignment operators take D3D12_CPU_DESCRIPTOR_HANDLE instead of the class type (CD3DX12_CPU_DESCRIPTOR_HANDLE) they can't simply be defaulted.

I don't know if there's a good way to indicate to analysis that the operator= method doesn't require *this to be initialized. Maybe the solution is to delete these operator= methods and remove explicit from the conversion constructor - then this assignment would construct a CD3DX12_CPU_DESCRIPTOR_HANDLE and use the defaulted operator=, which doesn't cause analysis to complain: https://godbolt.org/z/3Y49E5

jenatali avatar Mar 19 '21 20:03 jenatali

Paging @walbourn for an opinion on this.

jenatali avatar Mar 19 '21 20:03 jenatali

The =default instead of {} implementation of ctors/operators is important for other reasons, but it does mean that the static code analyzer 'notices' it is uninitialized.

If you choose to use an array of D3D12_CPU_DESCRIPTOR_HANDLE instead, it doesn't produce the warning.

It also doesn't happen if you use CD3DX12_CPU_DESCRIPTOR_HANDLE Handles[32] = {};

Frankly this looks more like a bug in /anazlye than anything else...

You should submit this repro as a bug to the VS team since I don't see any reason it should emit the warning.

walbourn avatar Mar 22 '21 19:03 walbourn

Does this warning still happen with the latest VS 2019?

walbourn avatar Aug 18 '21 19:08 walbourn

I see it still happens. This is definitely a compiler bug. Please report it to VS and then close this issue with the link.

walbourn avatar Aug 18 '21 19:08 walbourn

@EpicChrisWaters Did this get reported to the VS site yet?

walbourn avatar Sep 10 '21 21:09 walbourn