websocket-to-bytes signal type error about emacs-websocket

[ahyatt]

What version of emacs is this using, and is it compiled for 32 or 64 bits? I'm not sure why emacs is turning the integer into a float automatically, but I'm guessing this might happen on 32-bit emacs.

[sten0]

Hi Andrew, Andrew Hyatt <[email protected]> writes:

What version of emacs is this using, and is it compiled for 32 or 64 bits? I'm not sure why emacs is turning the integer into a float automatically, but I'm guessing this might happen on 32-bit emacs.

Yes, I think you're right. Emacs 26.3 on 32bit hardware. It affects i386 and armhf: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/emacs-websocket.html I assume the reason is because "An integer that is out of the Emacs range [eg: smaller on 32bit archs] is treated as a floating-point number" (https://www.gnu.org/software/emacs/manual/html_node/elisp/Integer-Basics.html). Cheers, Nicholas

[ahyatt]

Thanks for the clarification. Fixed in commit 5568114. It's possible that 27.1 will fix this as well for 32-bit systems, but I haven't tested. If you can test and see that merely running on 27.1 is enough to fix this, without my latest commit, then that would be good to know.

[sten0]

Hi Andrew, Andrew Hyatt <[email protected]> writes:

Thanks for the clarification. Fixed in commit 5568114. It's possible that 27.1 will fix this as well for 32-bit systems, but I haven't tested. If you can test and see that merely running on 27.1 is enough to fix this, without my latest commit, then that would be good to know.

Thank you for the quick fix! I'll "push my luck" and see how long it takes someone to notice the unpatched build is failing, and I expect it will be less than a month before we 27.1 moves from Debian experimental to unstable. Unfortunately it will also be about a month before I will have to time to set up a 32bit development VM, and of course that wouldn't be as valuable as a test on real hardware (eg: the buildd and DebCI networks). My feeling is 27.1 won't resolve the issue without 5568114, unless the out-of-bounds integer -> float behaviour was changed in 27.1, but yes, I'm happy to help test this hypothesis--it's the least I can do to thank you :-) I expect to have results in early October, and please feel free to send a ping/reminder at that time. Regards, Nicholas

[sten0]

P.S. While preparing a fix for the Debian package in case someone complain sooner rather than later, I took a quick look at the commit and saw that it it's a patch for the test. @ahyatt, assuming Emacs 27.1 doesn't change this behaviour, do you think this integer-to-float issue will cause functional problems for emacs-websocket users on 32bit archs?

[ahyatt]

The fix should fix the test on a 32 bit emacs. I've done some previous fixes for 32 bit systems on websockets, so I think there wouldn't really be a problem. It may be possible that extremely large frames that may cause a problem, however. That isn't likely to happen in real-world uses of websockets.

[sten0]

The fix should fix the test on a 32 bit emacs. I've done some previous

fixes for 32 bit systems on websockets, so I think there wouldn't really be a problem. It may be possible that extremely large frames that may cause a problem, however. That isn't likely to happen in real-world uses of websockets. Awesome, thank you, this information is truly appreciated! Also, I appreciate the wisdom that it's probably not worth further optimising for an unlikely case (extremely large frames) for 32bit, when 32bit is on it's way out, and when everyone who is likely to do something exotic like that is probably already on 64bit. If I understand b65328c correctly, the frame limit is 537M? That's already a huge amount of data! Also, having found b65328c, I can see the deeper value of 5568114 :-) Always a pleasure, Nicholas

[sten0]

Hi Andrew, Andrew Hyatt <[email protected]> writes:

Thanks for the clarification. Fixed in commit 5568114. It's possible that 27.1 will fix this as well for 32-bit systems, but I haven't tested. If you can test and see that merely running on 27.1 is enough to fix this, without my latest commit, then that would be good to know.

Confirmed, Emacs 27.1 appears to have changed the noted behaviour and thus fixed this issue on i386. Thanks again for the fix for i386 users on Emacs 26.3 (ie: Debian stable and Ubuntu 20.04 users on i386 will be able to install the updated package on their systems). Regards, Nicholas