AP_Proximity: avoid use of int16_t-read call #27445
Conversation
peterbarker
force-pushed
the
pr/int16-t-lifghtwaresf45b
branch
from
2948c2f to
e654096
Compare
| int16_t c = _uart->read(); | ||
| if (c==-1) { | ||
| return false; | ||
| for (auto i=0; i<INT16_MAX; i++) { // process at most n bytes |
There was a problem hiding this comment.
I guess it might make sense for this to be 1024 as well. I can imagine being hesitant to include functional changes that would require testing but what we have now is a bit dangerous.
There was a problem hiding this comment.
I guess it might make sense for this to be 1024 as well. I can imagine being hesitant to include functional changes that would require testing but what we have now is a bit dangerous.
Yes, bearing in mind I don't have the hardware to test this on :-)
INT16_MAX isn't disastrous - 32,000 iterations in here won't kill a vehicle.
Now AP_Proximity_Cygbot_D1 is a much greater concern - it's iterating up to UINT32_MAX, which will cause us to fall out of the sky. It's a good thing out UARTDriver layer is well-behaved :-)
There was a problem hiding this comment.
i think 1024 limit would be good
Tested in SITL using gdb and the simulated devices