CsWin32 should not wrap output handles with SafeHandle on errors
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 2.5k
- Forks
- 124
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 9
Description
Actual behavior
/// <inheritdoc cref="CreatePipe(winmdroot.Foundation.HANDLE*, winmdroot.Foundation.HANDLE*, winmdroot.Security.SECURITY_ATTRIBUTES*, uint)"/>
[SupportedOSPlatform("windows5.0")]
internal static unsafe winmdroot.Foundation.BOOL CreatePipe(out Microsoft.Win32.SafeHandles.SafeFileHandle hReadPipe, out Microsoft.Win32.SafeHandles.SafeFileHandle hWritePipe, winmdroot.Security.SECURITY_ATTRIBUTES? lpPipeAttributes, uint nSize)
{
winmdroot.Foundation.HANDLE hReadPipeLocal;
winmdroot.Foundation.HANDLE hWritePipeLocal;
winmdroot.Security.SECURITY_ATTRIBUTES lpPipeAttributesLocal = lpPipeAttributes.HasValue ? lpPipeAttributes.Value : default(winmdroot.Security.SECURITY_ATTRIBUTES);
winmdroot.Foundation.BOOL __result = WindowsPInvoke.CreatePipe(&hReadPipeLocal, &hWritePipeLocal, lpPipeAttributes.HasValue ? &lpPipeAttributesLocal : null, nSize);
hReadPipe= new Microsoft.Win32.SafeHandles.SafeFileHandle(hReadPipeLocal, ownsHandle: true);
hWritePipe= new Microsoft.Win32.SafeHandles.SafeFileHandle(hWritePipeLocal, ownsHandle: true);
return __result;
}
Expected behavior
MSDN documentation for CreatePipe states:
If CreatePipe fails, the contents of the output parameters are indeterminate. No assumptions should be made about their contents in this event.
CsWin32 should not assume that those output parameters will simply contain invalid handles.
Repro steps
NativeMethods.txtcontent:
CreatePipe
Context
- CsWin32 version:
0.1.619-beta - Win32Metadata version (if explicitly set by project):
15.0.22-preview - Target Framework:
net6.0 LangVersion(if explicitly set by project):preview
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the issue with a NativeMethods.txt containing CreatePipe, then trace the CsWin32 source-generator path that emits wrappers for output handles. Compare the generated wrapper with the CreatePipe failure contract shown in the issue. Done means failed calls do not blindly wrap indeterminate output parameters as SafeHandles, with coverage for this repro.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- devtools, operating-systems
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100