SrmRideFile: handle datacnt overflow

datacnt is 16bits so it overflows easily for large files (9 hours with
0.5sec recint).

I've also seen datacnt and block sum to be inconsistent in other cases.

To handle this more graceful, we're now taking the max of both counts and
let the EOF detection do it's job when one of them is wrong.

We do have to use one of these limits as some SRM files have junk after
their last chunk (so, just reading chunks till we get EOF retunrs this
junk, too).
This commit is contained in:
Rainer Clasen
2014-07-08 06:53:13 +02:00
parent fd5d7cfd7b
commit 7b42b863a1

View File

@@ -207,6 +207,7 @@ RideFile *SrmFileReader::openRideFile(QFile &file, QStringList &errorStrings, QL
}
blockhdr *blockhdrs = new blockhdr[blockcnt+1];
int blockchunkcnt = 0;
for (int i = 0; i < blockcnt; ++i) {
// In the .srm files generated by Rainer Clasen's srmcmd,
// hsecsincemidn is a *signed* 32-bit integer. I haven't seen a
@@ -217,6 +218,7 @@ RideFile *SrmFileReader::openRideFile(QFile &file, QStringList &errorStrings, QL
blockhdrs[i].chunkcnt = readShort(in);
blockhdrs[i].dt = QDateTime(date);
blockhdrs[i].dt = blockhdrs[i].dt.addMSecs(hsecsincemidn * 10);
blockchunkcnt += blockhdrs[i].chunkcnt;
}
// fail early to tell devs whats wrong with file
@@ -247,6 +249,13 @@ RideFile *SrmFileReader::openRideFile(QFile &file, QStringList &errorStrings, QL
blockhdrs[0].dt = QDateTime(date);
}
// datacnt might overflow at 64k - so, use sum from blocks, instead
if( datacnt > blockchunkcnt ){
blockchunkcnt = datacnt;
errorStrings << QString("inconsistent chunk count total=%1, blocks=%2")
.arg(datacnt)
.arg(blockchunkcnt);
}
int blknum = 0, blkidx = 0, mrknum = 0, interval = 0;
double km = 0.0, secs = 0.0;
@@ -254,7 +263,7 @@ RideFile *SrmFileReader::openRideFile(QFile &file, QStringList &errorStrings, QL
if (markercnt > 0)
mrknum = 1;
for (int i = 0; i < datacnt; ++i) {
for (int i = 0; i < blockchunkcnt; ++i) {
int cad, hr, watts;
double kph, alt;
double temp=-255;