Open infeo opened 2 years ago
#include <sal.h>
// Example callback function with SAL annotations
NTSTATUS DOKAN_CALLBACK MyDokanCreateFile(
LPCWSTR FileName,
PDOKAN_IO_SECURITY_CONTEXT SecurityContext,
ACCESS_MASK DesiredAccess,
ULONG FileAttributes,
ULONG ShareAccess,
ULONG CreateDisposition,
ULONG CreateOptions,
PDOKAN_FILE_INFO DokanFileInfo)
{
// Your implementation here
return STATUS_SUCCESS;
}
Summary
Add to all callbacks SAL annotations to indicate the intent of pointer paramters.
Description
First of all, i'm not a c++ programmer, so I don't know if this makes sense or is even feasible.
This question arose to me during the migration fom Dokany 1.x to 2.x. Newer functions like DokanCloseHandle(...) are using SAL annotations to indicate the usage intent of function parameters and so, reduce misuse of them.
From my point of view, such annotations would be also benefical for the dokan callbacks, since it is not always clear, which parameter struct can and should be altered. Especially this holds for the DokanFileInfo struct, since this one cannot be looked up in any Windows documentation.
As an example, in the sample mirrorfs, in the dokanFileInfo struct the directory attribute is set: https://github.com/dokan-dev/dokany/blob/1ffacd40d6ca402c2b49aec2b6fdddfa1a668fa6/samples/dokan_mirror/mirror.c#L274-L284 I would assume the kernel driver is responsible for setting such attributes correctly, but it seems like we have to deal with it.