Otherwise ubsan reports errors such as:
libs/vkd3d-shader/spirv.c:7266:5: runtime error: null pointer passed as argument 1, which is declared to never be null
Otherwise when passing "-fsanitize=undefined" to the compiler, ubsan
reports such as:
libs/vkd3d-shader/ir.c:3794:5: runtime error: null pointer passed as argument 1, which is declared to never be null
This way the same shader is always dumped to the same path and when
launching the same program over and over we avoid both creating new
copies of the same file each time and overwriting different dumped
shaders.
For tpf shader this would previously be a pointer into the original
shader code, and for d3dbc shaders we'd use static strings.
Unfortunately the dxil parser creates shader signatures where these
are pointers to metadata strings, and those go away when we call
sm6_parser_cleanup().
We could conceivably store a flag in the shader signature to indicate
whether shader_signature_cleanup()/vkd3d_shader_free_shader_signature()
should free the "semantic_name" field. It'd be a little ugly, and seems
unlikely to be worth it, but I'd be willing to be convinced.
After compiling and linking with '-fsanitize=undefined' the following
error pops up in many tests:
vkd3d_shader_main.c:2024:12: runtime error: member access within null pointer of type 'struct vkd3d_shader_param_node'
This happens in the scenario where shader_param_allocator_get() gets
called with 'count = 0' but no allocation has been made yet, so
allocator->current is NULL.
In this case the result of the function, given by:
params = &allocator->current->param[allocator->index * allocator->stride];
is an invalid non-NULL pointer.
Functions like shader_sm4_read_instruction() may call
vsir_program_get_src_params() or vsir_program_get_dst_params() with 0
counts for various DCL_ instructions, as well as things like NOP,
ELSE, and SYNC.
We could avoid calling the functions in question with 0 counts, but it
doesn't seem worth the effort.
Alternatively, we could just return NULL on 'count == 0', but this is
also complicated because NULL is interpreted as a memory allocation
failure on the callers.
So we force allocation of the next node even if 'count = 0' when
allocator->current is NULL.
The other cases are similar and common code can be refactored.
Ideally the HLSL parser will eventually fit the same model, but that
will require more extensive work.
