Refactor: remove TBuffer::processSocketData(char*, int)

[SlySven]

It really wasn't useful - it just refactored out some lines of code into a separate method for the cost of another function call...

Also fix a dodgy argument of the form (char*&) which was passing a char array anyhow.

A line mpHost->mInsertedMissingLF = false; is taken out by this PR but that member is never used and will be removed in another PR to be entered after this one.

Signed-off-by: Stephen Lyons slysven@virginmedia.com

[add-deployment-links]

Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

• linux: https://make.mudlet.org/snapshots/9c5a9b/Mudlet-4.8.2-testing-pr3830-79002d6-linux-x64.AppImage.tar
• osx: https://make.mudlet.org/snapshots/2971a7/Mudlet-4.8.2-testing-pr3830-79002d6.dmg
• windows: https://make.mudlet.org/snapshots/57936d/Mudlet-4.8.2-testing-pr3830-79002d64-windows.zip

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

[Kebap]

Refactor: remove TBuffer::processSocketData(char*, int)
It really wasn't useful - it just refactored out some lines of code into a separate method for the cost of another function call...

Actually looking at the code (not through it, can't be bothered), processSocketData is a massive bowl of spaghetti code still, which certainly warrants some refactorization - Whereas the not really useful function with 10 lines of code was called handle_socket_signal_readyRead - and still is, as it has now inherited ~170 lines from the aforementioned function.

I for one am not sure what the cost of another function call is, and would vote for having multiple small and indeed digestable functions rather. Not sure what is really gained here by attaching these 2 functions together into 1.

A line mpHost->mInsertedMissingLF = false; is taken out by this PR but that member is never used and will be removed in another PR to be entered after this one.

I like the idea of splitting changes into smaller PRs for easy review, but these items should still be linked in the same.

[SlySven]

As it happened I spotted these things whilst I was focussing on another aspect and I tried to extract each thing separately. I wasn't entirely successful and had to re add taking that line out in the other one so it would compile separately.

I hadn't paid attention to the history of how the (slot method as it happens) handle_socket_signal_readyRead() and processSocketData(...) came about - but it seems that @vadi2 put the latter in in PR #2337 "Refactor telnet socket read for unit testing / fuzzing". So it seems I have just reverted a change made about 20 months ago.

That being the case I will close this as it is not going in the direction we want to go.

[vadi2]

Have to agree with Kebap - many small functions with a clear purpose are better than one humongous one.