Skip to content
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

Ideally, there would be a distinct attribute for these "invented" handle types #1533

Closed
kennykerr opened this issue Apr 11, 2023 · 3 comments · Fixed by #1538
Closed

Ideally, there would be a distinct attribute for these "invented" handle types #1533

kennykerr opened this issue Apr 11, 2023 · 3 comments · Fixed by #1538
Assignees

Comments

@kennykerr
Copy link
Contributor

kennykerr commented Apr 11, 2023

Ideally, there would be a distinct attribute for these "invented" handle types, like MEMORYMAPPEDVIEW_HANDLE, to distinguish them from native types defs that are actually defined in the Windows SDK. Without this, languages like C++ and Rust that aim to preserve the original definitions more faithfully are now stuck not being able to distinguish between something like PSID which is actually defined by the Windows SDK and MEMORYMAPPEDVIEW_HANDLE which is not. I thought this was what the NativeTypeDef attribute was for but perhaps I misunderstood.

Originally posted by @kennykerr in #561 (comment)

@mikebattista
Copy link
Contributor

There are many manufactured NativeTypeDefs. How would you want those treated?

@kennykerr
Copy link
Contributor Author

Yes, I'm not sure how you'd untangle it as the metadata is increasingly tailored for the non-systems language consumers and you wouldn't want to break that. I may just fix this on my end.

@mikebattista
Copy link
Contributor

Below are all the manufactured [NativeTypeDef] structs.

How do we want to handle these assuming we want to reserve [NativeTypeDef] only for cases where a native typedef exists in the headers?

These all should still support AlsoUsableFor, RAIIFree, and InvalidHandleValue. Should we just use a different attribute besides [NativeTypeDef] as I believe you were suggesting? What should we call it?

BoundaryDescriptorHandle
CONTROLTRACE_HANDLE
CreatedHDC
CriticalPolicySectionHandle
DnsContextHandle
EventLogHandle
EventSourceHandle
FilterFindHandle
FilterInstanceFindHandle
FilterVolumeFindHandle
FilterVolumeInstanceFindHandle
FindChangeNotificationHandle
FindFileHandle
FindFileNameHandle
FindStreamHandle
FindVolumeHandle
FindVolumeMountPointHandle
FIRMWARE_TABLE_ID
GetDcContextHandle
HdcMetdataEnhFileHandle
HdcMetdataFileHandle
HeapHandle
HwtsVirtualChannelHandle
IcmpHandle
LOADIMAGE_HANDLE
NamespaceHandle
NetEnumHandle
PerfProviderHandle
PerfQueryHandle
PROCESSTRACE_HANDLE
RELOGSTREAM_HANDLE
sa_family_t
ShFindChangeNotificationHandle
TimerQueueHandle
UPDATERESOURCE_HANDLE

@mikebattista mikebattista self-assigned this Apr 13, 2023
mikebattista added a commit that referenced this issue Apr 17, 2023
…y in metadata (#1538)

* Initial attempt at fixing #1533 for review.

* Refactored attribute to Typedef(Native = true/false). Added missing native typedefs.

* Fixed build break.

* Updated the baseline.

* Refactored to MetadataTypedef.

* Removed extra ')'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants