question about cochran.c

[Dirk Hohndel]

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