and frankly unreliable because you can get stuck here!
If there is no serial data, there is nothing to do, so the while loop doesn't get executed. How can you possibly get stuck? Neither Serial.available() or Serial.read() are blocking functions.
But that bit of code is still a crummy solution.
First, the buffer size if only 128 bytes. It wouldn't take that long to read and discard the entire buffer.
Second, there are very few legitimate uses of the flush function.
It's just poor design to let it be done this way. Ultimately, it's these kind of compromises that will make Arduino get even slower than it already is.
QuoteSecond, there are very few legitimate uses of the flush function.At a user sketch level its totally valid. If you have a particularly verbose module, it can be constant spewing stuff into the serial port. If you are only interested in query-response, then you would want to be able to flush the serial buffer.
I completely fail to see how this change makes anything slower.
You say it is valid and then propose a completely invalid situation. If you really feel the need to flush the serial buffer so that you only see the "response" you are interested in, you have to write your own flush method anyway. You would need to flush everything except for tokens that you want to see.
If on the other hand you want to just dump whatever is in the Serial Receive buffer, a simple for loop will do that.
Re-purposing flush to the transmit makes sense now that the transmit buffer is asynchronous.
In general many request/response protocols require the ability to flush the incoming receive buffer if a bad frame is detected.