-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
std.os.windows: add missing null terminator on various kernel32 signatures #22083
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
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: var wtf16le_buf: [256:0]u16 = undefined;
// Have to pass len + 1 since the NUL-terminator should be included in the buffer length
const result = std.os.windows.kernel32.GetCurrentDirectoryW(wtf16le_buf.len + 1, &wtf16le_buf);
if (result == 0) return error.Foo;
// GetCurrentDirectoryW returns the length not including the terminator
const cur_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: var wtf16le_buf: [256]u16 = undefined;
const result = std.os.windows.kernel32.GetCurrentDirectoryW(wtf16le_buf.len, &wtf16le_buf);
if (result == 0) return error.Foo;
// GetCurrentDirectoryW returns the length not including the terminator
const cur_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:
|
|
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. 😕 |
|
I would argue that |
I think you are correct. I will close this PR. Maybe the issue should also get closed now? |
Closes #19949 .