Skip to content

Conversation

@Aidan63
Copy link
Contributor

@Aidan63 Aidan63 commented Dec 13, 2025

Seems like there were two problems here.

One is something only msvc flagged up, the get and set functions on the value type reference has an ambigious conversion if the function it calls accepts int64_t.

The other is that the type apple clang uses for size_t doesn't have a dynamic conversion, so I've just switched the last few size_t references to int64_t (I'll also update the haxe extern).

@tobil4sk
Copy link
Member

The other is that the type apple clang uses for size_t doesn't have a dynamic conversion, so I've just switched the last few size_t references to int64_t (I'll also update the haxe extern).

Would it not be possible to add the dynamic conversion for this type? size_t seems to be the more natural and correct type for this, and it matches the convention of the c++ std. It is also more portable across architectures.

@Aidan63
Copy link
Contributor Author

Aidan63 commented Dec 13, 2025

That was my initial thought and I do think it would be the better approach, but implementing that seems like it might be a bit tricker due to the varying size of size_t.

Many of the macros to add all the dynamic support for a type seem to except a fixed size, but to support size_t we'd need to add a bunch of extra conditionals for the size_t case. Or just go for the pessimistic approach and always box size_t as an int64, even if it's a 32bit build.

This should get the CI green for now atleast.

@Simn Simn merged commit 4b2991f into HaxeFoundation:master Dec 14, 2025
120 checks passed
@Simn
Copy link
Member

Simn commented Dec 14, 2025

Huh... CI was green here, but after merging there's now this failure on 32bit linux latest:

unit.TestBytes
  test: FAILURE ........................................F...F............................................................................................................................
    line: 51, expected 66 but it is 67
    line: 57, expected 66 but it is 67

@Aidan63
Copy link
Contributor Author

Aidan63 commented Dec 14, 2025

Hmm, that is odd. I just did a HXCPP_M32 build of the haxe test suite locally in WSL and that passed fine. Those failing tests don't indicate anything either, just one of many charCodeAt and bytes get tests.

32bit linux haxe tests were also passed fine with the initial merge.

@Simn
Copy link
Member

Simn commented Dec 14, 2025

It's green after restarting the run. No idea what happened there, I guess we'll see if it happens again!

@Aidan63 Aidan63 deleted the no-sizet branch December 14, 2025 11:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants