There are multiple bugs in sensorcal related to the serial number.
Line 90 claims the the serial number is 6 characters -- which matches the data structure in 24c16.h
Line 127 does strcpy (data.serial,"000000") --- This is an issue because strcpy will terminate with a 0x00 at the end, which means it's actually loading 7 bytes into a 6 byte array likely messing up the first byte of zero_offset. Fortunately, this is not a serious problem since line 128 initializes zero_offset to 0.
Lines 192-196 Load 7 bytes into data.serial, again... This is probably not a big deal because the data structure in the RAM and the EEPROM presumably match, which means you're corrupting the 1st byte of zero_offset with itself.
Line 197 adds a "\n" to the end of it, corrupting the second byte of zero_offset. This makes no sense since a string should be terminated by a 0x00 not a \n. Unlike line 127, after executing line 197, line 201 is executed which writes the now corrupted data back into the EEPROM.
I propose to add a local variable char s[7] to deal with lines 192-198:
Line 127: changes from strcpy("000000",data.serial) to memstr(data.serial,'0',6)
Line 192: changes from i<7 to i<6
Line 194: changes from data.serial[i]=optarg to data.serial[i]=s[i]=optarg
Line 197: changes from data.serial[7]='/n' to s[6]=0;
Line 198: changes from data.serial to s
I'll fix these after I get my voltage and temperature pulls merged.
There are a few additional issues where we are ignoring return values which we probably shouldn't throughout sensord, but I wouldn't necessarily call those bugs and are probably lower priority.
There are multiple bugs in sensorcal related to the serial number.
Line 90 claims the the serial number is 6 characters -- which matches the data structure in 24c16.h
Line 127 does strcpy (data.serial,"000000") --- This is an issue because strcpy will terminate with a 0x00 at the end, which means it's actually loading 7 bytes into a 6 byte array likely messing up the first byte of zero_offset. Fortunately, this is not a serious problem since line 128 initializes zero_offset to 0.
Lines 192-196 Load 7 bytes into data.serial, again... This is probably not a big deal because the data structure in the RAM and the EEPROM presumably match, which means you're corrupting the 1st byte of zero_offset with itself.
Line 197 adds a "\n" to the end of it, corrupting the second byte of zero_offset. This makes no sense since a string should be terminated by a 0x00 not a \n. Unlike line 127, after executing line 197, line 201 is executed which writes the now corrupted data back into the EEPROM.
I propose to add a local variable char s[7] to deal with lines 192-198: Line 127: changes from strcpy("000000",data.serial) to memstr(data.serial,'0',6) Line 192: changes from i<7 to i<6 Line 194: changes from data.serial[i]=optarg to data.serial[i]=s[i]=optarg Line 197: changes from data.serial[7]='/n' to s[6]=0; Line 198: changes from data.serial to s
I'll fix these after I get my voltage and temperature pulls merged.
There are a few additional issues where we are ignoring return values which we probably shouldn't throughout sensord, but I wouldn't necessarily call those bugs and are probably lower priority.