Re: [PATCH v2 0/11] MR103: DXBC handling API

[Giovanni Mascellani (＠giomasce)]

Giovanni Mascellani (@giomasce) commented about include/vkd3d_shader.h:
> -
> - \n
> -
> - The output blob is allocated by vkd3d-shader and should be freed with
> -
> - vkd3d_shader_free_shader_code() when no longer needed.
> -
> -
> -
> - \param messages Optional output location for error or informational messages
> -
> - produced by the serialiser.
> -
> - \n
> -
> - This parameter behaves identically to the \a messages parameter of
> -
> - vkd3d_shader_compile().
> -
> -
> -
> - \return A member of \ref vkd3d_result.
> -
> -
> -
> - \since 1.7
> - */
>
> +VKD3D_SHADER_API int vkd3d_shader_serialize_dxbc(size_t section_count,
> -
>    const struct vkd3d_shader_dxbc_section_desc *sections, struct vkd3d_shader_code *dxbc, char **messages);

I am tempted to say we might want to allow for specifying the tag and version here too. Or rather take a `struct vkd3d_shader_dxbc_desc` as input and ignore size and checksum (or even allow for flags to use them even if they're invalid).

Not that I have any real usage in mind, of course, so that should probably be ignored. I happen to like symmetry, and I don't see reason for having the parsing interface allowing for the hypothesis that a format change might in theory happen, and the serializing interface not doing the same.