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.

Sign up for GitHub

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

Jump to bottom

Inconsistent Type Mapping Of Size_T Parameters #212

Open
Rosst0pher opened this issue Jan 13, 2022 · 0 comments
Open

Inconsistent Type Mapping Of Size_T Parameters #212

Rosst0pher opened this issue Jan 13, 2022 · 0 comments
Labels
Bug

Comments

@Rosst0pher
Copy link
Contributor

PInvoke methods and callbacks with size_t parameters or returns is inconsistently typed across SFML.Net.

Majority use uint

  • sfVideoMode_getFullScreenModes
  • sfRenderTexture_drawPrimitives
  • sfRenderWindow_drawPrimitives
  • sfShader_setFloatUniformArray
  • sfShader_setVec2UniformArray
  • sfShader_setVec3UniformArray
  • sfShader_setVec4UniformArray
  • sfShader_setMat3UniformArray
  • sfShader_setMat4UniformArray
  • sfShape_create
  • sfText_findCharacterPos
  • sfVertexArray_getVertexCount
  • sfVertexArray_getVertex
  • sfVertexArray_resize
  • sfSoundRecorder_create
  • sfSoundRecorder_getAvailableDevices

A few others use ulong

  • sfFront_createFromMemory
  • sfImage_createFromMemory
  • sfTexture_createFromMemory
  • sfMusic_createFromMemory
  • sfSoundBuffer_createFromMemory

given that size_t size is platform dependent, I believe in C# you'd normally use IntPtr, UIntPtr or the newer nint or nuint types in place of size_t. I'm not sure in detail what the consequences are for the current mappings of size_t but I think this was worth raising going forward as .NET does have preferred types for platform dependent sized types.
@eXpl0it3r eXpl0it3r added the Bug label Jan 13, 2022
DemoXinMC added a commit to DemoXinMC/SFML.Net that referenced this issue Jan 3, 2024
@DemoXinMC
Unify all size_t arguments to use uint
7859737 
Somewhat addresses SFML#212
* Updated to use uint consistently where CSFML is expecting size_t
* UIntPtr is the most correct type for size_t, but switching to it would result in breaking changes for end users
* uint should be replaced with nuint when moving to .NET 5+
@DemoXinMC DemoXinMC mentioned this issue Jan 3, 2024
Closed
DemoXinMC added a commit to DemoXinMC/SFML.Net that referenced this issue Jan 3, 2024
@DemoXinMC
Unify all size_t arguments to use uint
547885d 
Somewhat addresses SFML#212
* Updated to use UIntPtr where CSFML is expecting size_t
* Since all changes are within protected code, should not represent a breaking change for end-users
* UIntPtr should be replaced with nuint when moving to .NET 5+
* Implemented Font(byte[]) properly using sfFont_createFromMemory() instead of creating a new MemoryStream
DemoXinMC added a commit to DemoXinMC/SFML.Net that referenced this issue Jan 3, 2024
@DemoXinMC
Unify all size_t arguments to use UIntPtr
f412143 
Addresses SFML#212
* Updated to use a SIZE_T "macro" where CSFML is expecting `size_t`
* `using SIZE_T = UIntPtr;` is at the beginning of each file that will P/Invoke functions with `size_t` signatures
* SIZE_T is currently typedef'd to `UIntPtr` but this can be changed when `nuint` becomes available to SFML.NET (.NET 5+)
* Since all changes are within protected/private code, this should not represent a breaking change for end-users

* Implemented Font(byte[]) properly using sfFont_createFromMemory() instead of creating a new MemoryStream
@DemoXinMC DemoXinMC mentioned this issue Jan 3, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@eXpl0it3r @Rosst0pher