Yes, that's frequently done in win32 land, but in this case, I'd argue the following should have been done
1) Why provide a copy of the parameter at the end of a struct?
2) How will you ever expand that struct given the fact that you put a variably-sized member at the end?
3) Why doesn't the current version of the header come with a
char[] SessionName;
member as last member, so it's at least halfway convenient?
4) No seriously - why is it copied in at the end and not a pointer?
5) That struct doesn't even have a DWORD size member as first member, are we expecting to get coupling between some flag and "oh and expect there to be additional members after that char array"?
> No seriously - why is it copied in at the end and not a pointer?
Consider where you have seen similar patterns in the Unix world. The obvious one would be they intend to pass the buffer to kernel mode and a structure with lots of pointers inside will be a pain in the ass to pass over and validate.
A flat buffer with a couple of offsets works better for that. Copy over the whole blob, check a few lengths. Generate your EFAULT errors in a single place. Better than following lots of user mode pointers.
1) Why provide a copy of the parameter at the end of a struct?
2) How will you ever expand that struct given the fact that you put a variably-sized member at the end?
3) Why doesn't the current version of the header come with a
member as last member, so it's at least halfway convenient?4) No seriously - why is it copied in at the end and not a pointer?
5) That struct doesn't even have a DWORD size member as first member, are we expecting to get coupling between some flag and "oh and expect there to be additional members after that char array"?
Even for Win32's usual badness, it's pretty bad.