Re: [PATCH 0/2] MR44: vkd3d-shader/dxil: Read and validate DXIL bitcode blocks.

[Giovanni Mascellani (＠giomasce)]

Giovanni Mascellani (@giomasce) commented about libs/vkd3d-shader/dxil.c:
> - return CONTAINING_RECORD(parser, struct vkd3d_shader_sm6_parser, p);
>
> +}
> -
>
> +static void shader_sm6_reset(struct vkd3d_shader_parser *parser)
> +{
> - parser->failed = false;
>
> +}
> -
>
> +static bool shader_sm6_is_end(struct vkd3d_shader_parser *parser)
> +{
> - struct vkd3d_shader_sm6_parser *sm6 = vkd3d_shader_sm6_parser(parser);
> -
> - return parser->ptr == sm6->end;
>
> +}
> -
>
> +static inline unsigned int shader_sm6_read_uint32(struct vkd3d_shader_parser *parser)

Here and in other places it would feel more natural to use `uint32_t` instead of `unsigned int`, even if they end up being the same thing on all architectures we care about. You sometimes use fixed-width types and sometimes don't. Is there a logic for that? Since I guess that DXIL/LLVM specifications mandate the bit width for basically everything, I'd say that it makes sense to always use fixed-width integer types.