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

Refactored types in frame to use size_t (#fix 34) #35

Closed
wants to merge 1 commit into from

Conversation

o3o
Copy link

@o3o o3o commented Feb 14, 2024

It compiles to ARM, but
I have a doubt about line 124.

writeDataOrThrow(ptr, cast(ulong) frame.payload.length);

perhaps it should be changed to cast(size_t)?

Comment on lines +226 to +230
private size_t readPayloadLength(S)(ubyte initialLength, S stream) if (isByteInputStream!S) {
if (initialLength == 126) {
return readDataOrThrow!(ushort)(stream);
} else if (initialLength == 127) {
return readDataOrThrow!(ulong)(stream);
return readDataOrThrow!(size_t)(stream);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The specification requires that the payload length be encoded as 64 bits if the initial length is 127, so it's gotta stay as readDataOrThrow!(ulong)(stream). I guess the best thing to do would be return cast(size_t) readDataOrThrow!(ulong)(stream);

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you are right, the frame length could be 64bit, but if I use ulong in 32 arm the compiler complains. I could do a cast from ulong to uint, but if actually the package is bigger than uint it generates a conversion error.... I have to think more about it. Thanks for the great support

@andrewlalis
Copy link
Owner

Regarding your question about line 124, the writeDataOrThrow call there does need to write a ulong, since the spec requires 64 bits in that part of the frame. ARM only seems to complain when a long or ulong is used instead of size_t when doing array indexing operations.

@andrewlalis andrewlalis self-assigned this Feb 14, 2024
@andrewlalis
Copy link
Owner

Also, referencing #34 so that GitHub knows the issue is linked to this pr.

@andrewlalis andrewlalis linked an issue Feb 14, 2024 that may be closed by this pull request
@andrewlalis
Copy link
Owner

Closing this because I implemented your changes, plus the details I mentioned in commit 4a22ed4

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.

Compilation Issue on Raspberry Pi
2 participants