std.os.windows: add missing null terminator on various kernel32 signatures

[HydroH]

Closes#19949 .

[squeek502]

I'm not sure these changes make sense. All of these are out parameters, meaning the null terminator is written by the function, so the input being null-terminated is irrelevant. Further, in terms of usage, I think it makes more sense for these parameters to not be defined as null-terminated.

For example, if these parameters are defined with a null-terminator, the correct usage would look something like this:

varwtf16le_buf: [256:0]u16=undefined;
// Have to pass len + 1 since the NUL-terminator should be included in the buffer lengthconstresult=std.os.windows.kernel32.GetCurrentDirectoryW(wtf16le_buf.len+1, &wtf16le_buf);
if (result==0) returnerror.Foo;
// GetCurrentDirectoryW returns the length not including the terminatorconstcur_dir=wtf16le_buf[0..result :0];

If it's not defined with a null terminator, the usage is more intuitive since just passing the length of the buffer is correct:

varwtf16le_buf: [256]u16=undefined;
constresult=std.os.windows.kernel32.GetCurrentDirectoryW(wtf16le_buf.len, &wtf16le_buf);
if (result==0) returnerror.Foo;
// GetCurrentDirectoryW returns the length not including the terminatorconstcur_dir=wtf16le_buf[0..result :0];

So, the buffer being defined as NUL-terminated doesn't gain us anything and makes it less likely that the correct length of the buffer will be passed to the function.

(I've made this same point before on this PR, but wasn't aware of #19949)

---

This comment is also relevant:

I believe this lpBuffer change [for GetEnvironmentVariableW] would actually cause a compile error in std.os.windows.GetEnvironmentVariableW, but since it's not used anywhere, it's not detected (we have std.process.getenvW that serves the same purpose).

[alexrp]

Good catch, I hadn't considered that nuance. I think I agree with your reasoning.

It does seem a bit unfortunate that the language feature designed specifically to represent this concept doesn't apply cleanly here, though. But I don't know that I have any concrete suggestions for improving that. 😕

[squeek502]

I would argue that [*]u16 does apply fairly cleanly here. If there was to be a more accurate parameter type, it'd have to represent "is an arbitrary buffer that will become sentinel-terminated after this function returns." That sort of thing seems like the domain of doc comments, though.

[HydroH]

I'm not sure these changes make sense. All of these are out parameters, meaning the null terminator is written by the function, so the input being null-terminated is irrelevant. Further, in terms of usage, I think it makes more sense for these parameters to not be defined as null-terminated.

For example, if these parameters are defined with a null-terminator, the correct usage would look something like this:

varwtf16le_buf: [256:0]u16=undefined;
// Have to pass len + 1 since the NUL-terminator should be included in the buffer lengthconstresult=std.os.windows.kernel32.GetCurrentDirectoryW(wtf16le_buf.len+1, &wtf16le_buf);
if (result==0) returnerror.Foo;
// GetCurrentDirectoryW returns the length not including the terminatorconstcur_dir=wtf16le_buf[0..result :0];

If it's not defined with a null terminator, the usage is more intuitive since just passing the length of the buffer is correct:

varwtf16le_buf: [256]u16=undefined;
constresult=std.os.windows.kernel32.GetCurrentDirectoryW(wtf16le_buf.len, &wtf16le_buf);
if (result==0) returnerror.Foo;
// GetCurrentDirectoryW returns the length not including the terminatorconstcur_dir=wtf16le_buf[0..result :0];

So, the buffer being defined as NUL-terminated doesn't gain us anything and makes it less likely that the correct length of the buffer will be passed to the function.

(I've made this same point before on this PR, but wasn't aware of #19949)

---

This comment is also relevant:

I believe this lpBuffer change [for GetEnvironmentVariableW] would actually cause a compile error in std.os.windows.GetEnvironmentVariableW, but since it's not used anywhere, it's not detected (we have std.process.getenvW that serves the same purpose).

I think you are correct. I will close this PR. Maybe the issue should also get closed now?