Why is MemorySize applied to WriteFile?

[AArnott]

I expect arrays to be identified with the NativeArrayInfoAttribute, but WriteFile's lpBuffer parameter uses MemorySizeAttribute instead.

public unsafe static extern BOOL WriteFile([In] HANDLE hFile, [Optional][In][Const][MemorySize(BytesParamIndex = 2)] byte* lpBuffer, [In] uint nNumberOfBytesToWrite, [Optional][Out] uint* lpNumberOfBytesWritten, [Optional][In][Out] OVERLAPPED* lpOverlapped);

MemorySizeAttribute is already used elsewhere for a different purpose. Instead of describing the length of a byte array, it describes the size of just one struct as in SHGetFileInfo:

public unsafe static extern UIntPtr SHGetFileInfoW([In][Const] PWSTR pszPath, [In] FILE_FLAGS_AND_ATTRIBUTES dwFileAttributes, [Optional][In][Out][MemorySize(BytesParamIndex = 3)] SHFILEINFOW* psfi, [In] uint cbFileInfo, [In] SHGFI_FLAGS uFlags);

So it seems MemorySizeAttribute plays dual roles: it is used on pointers to arrays like lpBuffer and indicates the length of the array, and also on pointers to a single struct like psfi and indicates the size of one struct.

It is impossible to discern whether a pointer parameter with this attribute applied is an array or not without building some discrimination into it (e.g. byte* must mean length of an array, and all other parameter types must mean size of one struct).

Is this really by design? Or should we fix WriteFile to use NativeArrayInfo instead?

[AArnott]

See also microsoft/CsWin32#913 where this caused a bug in CsWin32.

[mikebattista]

MemorySize is being applied instead of NativeArrayInfo when the SAL annotations use byteCount instead of elementCount.

[AArnott]

Ok. I'll go forward with CsWin32's approach of special cases byte* then. Thanks.

[mikebattista]

I think the generic way of thinking of MemorySize is whatever you're passing in for this parameter, pass its size to the parameter indicated by BytesParamIndex.