I'm idly working through the Coverity reports that we are now getting daily thanks to the wonderful GitHub Action provided by Anton Lundin.
I stumbed about an odd precision error that we've had for ages in cochran.c - and the more I look at the code, the more I wonder if this isn't a very different bug, actually. https://scan4.coverity.com/reports.htm#v33454/p13160/g33454g/fileInstanceId=68978672&defectInstanceId=11836151&mergedDefectId=45175 (I don't know if these links actually work for people without a Coverity account...) Here's the code in question: dc->watertemp.mkelvin = C_to_mkelvin((log[CMD_MIN_TEMP] / 32) - 1.8); Coverity rightfully points out that it would be better to do this as a floating point division. But looking at the formula I went... Hu??? A quick grep shows me that this is the odd one out: $ grep 1\\.8 core/cochran.c sample->temperature.mkelvin = C_to_mkelvin((temp - 32) / 1.8); dc->watertemp.mkelvin = C_to_mkelvin((log[CMD_MIN_TEMP] / 32.0) - 1.8); dc->watertemp.mkelvin = C_to_mkelvin((log[EMC_MIN_TEMP] - 32) / 1.8); dc->watertemp.mkelvin = C_to_mkelvin((min_temp - 32) / 1.8); Yeah, that seems to make more sense. And ideally, all of them should do the division in floating point (dividing by 32.0). John, I don't have any hardware to test this. Instead of me trying to hack this blind, would you like to send a pull request to fix the (I think, obvious) bug and maybe clean up the math and make it consistent? Thanks /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
