I suppose the copy was done to avoid returning an oversized buffer, but I'd expect that the returned buffer won't be kept around for long, and the copy operation can be expensive. The caller can still decide to trim the buffer themselves, if so they wish.Actually, a good chunk of the reason was simply avoiding the complication of transferring ownership of the underlying allocation from the string buffer to the vkd3d_shader_code structure. (I.e., vkd3d_shader_code_from_string_buffer(), essentially.)
It doesn't seem that complicated, though, does it? Helper `vkd3d_shader_code_from_string_buffer()` even abstracts it properly, but it seems to me we're willing to tolerate way worse encapsulation violations, aren't we?
On the other hand, saving a buffer copy might be a better-than-negligible gain. I didn't measure specifically here, but `spirv.c` has a similar feature, and with callgrind I've seen a significant amount of time spent there (I have a few patches about that I intend to eventually submit).