If we're cleaning things up, I'd argue for moving the SM4 parser out of dxbc.c, into its own file, like sm4.c or perhaps tpf.c.
That seems reasonable.
I'd also argue for merging hlsl_sm4.c and sm4.h into the same file.
This may also be reasonable, although I think it may depend on more prototyping being done first...
Not sure I understand?
As it happens, I have a bit of a dislike for the strn*() functions. You'll find very few of them in vkd3d or wined3d...
I don't understand this one. I suspect the prescription is "use memchr() instead", but that's less convenient. I can see how strncat() and strncpy() are fundamentally broken, but I don't see why the same applies to strnlen(), at least in this case. (Granted, this may be the only usage where strnlen() ever makes sense, but...)
It's probably fine here; it's just not my favourite family of functions.
This cuts about 7 kB off of the 64-bit build.
Is that a debug build, or stripped? Avoiding pointers in struct vkd3d_sm4_opcode_info is generally desirable, but I'd expect the "read_opcode_func" field to be the bigger problem with that. Ideally we'd get rid of the linear search as well...
It applies to both stripped and unstripped builds. (Actually, the benefit is more like 12 kB on this machine, not sure what changed.)
I suspect there is a more salient benefit in speed, but I didn't really want to put the effort into measuring that, and the size benefit seemed worthwhile by itself.
In theory it saves some relocations, and the arrays themselves are also smaller than 64-bit pointers. Still, the difference seemed slightly larger than I'd expect. Looking at the number of entries in the table though, perhaps it's not unreasonable.