erts, kernel: Little-endian packet header lengths
Add support for little-endian packet header lengths in gen_tcp and erlang:decode_packet, for lengths of two, three and four.
Add support for packet header lengths of three, both LE and BE.
The packet option can now be a tuple {Len, Endianness}, where Len can be 2, 3 or 4 and Endianness can be big or little. If endianness is big the behavior is the same as the old options.
Requested in issue #7265.
Other notes:
- the tuple option was suggested in the issue, I added
bigfor symmetry - for the inet backend I used the enum meta-type and had to change the
type_val_1clauses for it to work; there could be a better way, the option now has different possible types - the code I added in
gen_tcp_socket:sendcould be simplified since at that stage the option is already validated? - the tests for the tuple with big-endian option were commented out to reduce the total test time, but maybe they should be enabled; I tested locally, and they passed, I commented out after the fact.
CT Test Results
4 files 201 suites 1h 50m 25s ⏱️ 3 119 tests 2 803 ✅ 306 💤 10 ❌ 4 100 runs 3 678 ✅ 385 💤 37 ❌
For more details on these failures, see this check.
Results for commit ab146d63.
:recycle: This comment has been updated with latest results.
To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.
See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.
Artifacts
// Erlang/OTP Github Action Bot
This is something that should be discussed by OTP - technical board. I will put it on the schedule but as it is vacation period I think we will alas not have any conclusion before autumn, thankyou for your patience.
This is something that should be discussed by OTP - technical board. I will put it on the schedule but as it is vacation period I think we will alas not have any conclusion before autumn, thankyou for your patience.
I understand. I will wait for future updates, thank you.
My oppinion on this is that, as we are transitioning away from the inet driver, we should add this functionality in the socket backend via allowing a fun for packet. Then everyone can implement their own favourite packet mode without it having to be part of the stdlib.
Note: the failed checks are due to the missing preloaded bootstrap, as per project rules.
I think taking a fun as parameter is very interesting, but I'm not sure how it would work with erlang:decode_packet.
I will wait for further updates, thank you.