The Linux version doesn't (yet) buffer overflow because it's receiving less than 500 bytes at a time (a combination of more CPU power and faster standard output as it's not speed limited by the serial port). The potential buffer overflow is still there on Linux, it just isn't triggered as easily (some combination of CPU load and network load would eventually trigger it).
EDIT: actually a better explanation of why the Linux version doesn't crash is that the first byte of data after the 500 byte buffer happens to be zero. You can't rely on this , though!
Here's the ESP32 main.cpp file modified to avoid the buffer overflow. This works for me, whereas the previous version triggers a fatal exception or produces garbage output: https://gist.github.com/projectgus/8596 ... a6f0b5fbfa
Some tips for things to read about in order to gain more skills with this kind of network code development:
- Learn what a null-terminated string is in C, and what the difference between a string and a char buffer is in C. Knowing this difference will help you understand why the code above fixes the problem, whereas increasing the buffer size to 500 did not.
- Read the 'man' pages for recv, connect, socket. Update your code to check results from these.
- You'll probably want to adapt your code to use 'select' at some point.
- In your code, remember that a single call to recv() can return any number of bytes (TCP is a byte stream not a packet stream) - so you can receive anything between 0 whole lines of output (ie a partial incomplete line) and multiple lines of output from the server in one hit. You'll need to accumulate that raw data into a buffer, and then parse that buffer for lines of output.