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

Use fixed width integers for underlying enum types #443

Open
Ryan-rsm-McKenzie opened this issue Jan 25, 2024 · 1 comment
Open

Use fixed width integers for underlying enum types #443

Ryan-rsm-McKenzie opened this issue Jan 25, 2024 · 1 comment
Assignees
Labels
conformance wsl Related to Windows Subsystem for Linux support

Comments

@Ryan-rsm-McKenzie
Copy link
Contributor

All enums exposed in the api use either the default int or unsigned long for their underlying type. This is an issue for building ffi bindings, because the size of these types vary across platforms. In particular, sizeof(unsigned long) is 4 on windows, but 8 on linux. Based on your code, you expect these enums to have an exact width consistent across platforms, so it should be simple enough to declare all enums using uintN_t as their underlying type.

@walbourn walbourn added wsl Related to Windows Subsystem for Linux support conformance labels Jan 25, 2024
@walbourn walbourn self-assigned this Jan 30, 2024
@walbourn
Copy link
Member

walbourn commented Feb 27, 2024

The joys of LP64 vs. LLP64.

Type           ILP64   LP64   LLP64
char              8      8       8
short            16     16      16
int              64     32      32
long             64     64      32
long long        64     64      64
pointer          64     64      64

Thanks for the feedback. I'm debating the right solution here. I had originally used DWORD for flags to be consistent with Win32 standards, but over the years I've moved towards C++ standard types wherever possible. Since DWORD is a unsigned long I converted my usage to that so that it would still be the same as using DWORD including the way the types are mangled--there were some really sketchy client scenarios at work.

I don't know that maintaining the link compatibility of DWORD is still needed. I'll need to try some things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conformance wsl Related to Windows Subsystem for Linux support
Projects
None yet
Development

No branches or pull requests

2 participants