enforce field limits - #228
Conversation
As explained here openambitproject#218 sometimes we get wrong values from the watches, and when uploading the move, movescount reject it. So avoid to post wrong values to movescount.
|
Are you sure you shouldn't just "overflow" the values instead of dropping them? |
|
Well, as far as I can tell, dropping speed, vertical speed, energyconsumption and bike power fixes the problem, so those fields looks optional. That's why I sent a PR to display errors uploading moves, to see this kind of problems. |
centic9
left a comment
centic9
left a comment
There was a problem hiding this comment.
Some checks seem to not have any effect, can you review if these are false positives in CLion or really not changing behavior?
| break; | ||
| case ambit_log_sample_periodic_type_longitude: | ||
| output.insert("Longitude", (double)value->u.longitude/10000000); | ||
| if (value->u.longitude != 0xffffffff && value->u.longitude <= 180 && value->u.longitude >= -180){ |
There was a problem hiding this comment.
same warning about comparison to 0xff...
| break; | ||
| case ambit_log_sample_periodic_type_bikepower: | ||
| if (value->u.bikepower != 0xffff) { | ||
| if (value->u.bikepower != 0xffff && value->u.bikepower <= 2000) { |
There was a problem hiding this comment.
CLion reports a reduntant check on the comparison to 0xff..
There was a problem hiding this comment.
In this case the idea is to check if bikepower is present and if it is, include it only if it's lower than 2000. Sometimes I get >= 3000 values.
E.g. values of type unit8_t it cannot be higher than 255 anyway Remove some unused includes
If we check for >=, the check for 0xfffffff is not necessary any longer
3 participants
As explained here #218
sometimes we get wrong values from the watches, and when uploading the
move, movescount reject it. So avoid to post wrong values to movescount.