bugfix in rich unpacker
This MR fixes a bug in RICH unpacker, that is shown by the following compiler warnings:
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx: In function 'std::__cxx11::string mRichSupport::GetWordHexRepr(const uint8_t*)':
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx:69:32: warning: 'snprintf' output truncated before the last format character [-Wformat-truncation=]
snprintf(cStr, buf_size - 1, "%02x%02x %02x%02x", byte[0], byte[1], byte[2], byte[3]);
^~~~~~~~~~~~~~~~~~~
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx:69:11: note: 'snprintf' output 10 bytes into a destination of size 9
snprintf(cStr, buf_size - 1, "%02x%02x %02x%02x", byte[0], byte[1], byte[2], byte[3]);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx: In function 'std::__cxx11::string mRichSupport::GetBinaryRepresentation(size_t, const uint8_t*)':
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx:23:36: warning: 'snprintf' output truncated before the last format character [-Wformat-truncation=]
snprintf(cStr, buf_size - 1, "%u", byte);
^~~~
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx:23:15: note: 'snprintf' output 2 bytes into a destination of size 1
snprintf(cStr, buf_size - 1, "%u", byte);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx: In function 'std::__cxx11::string mRichSupport::GetHexRepresentation(size_t, const uint8_t*)':
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx:47:34: warning: 'snprintf' output truncated before the last format character [-Wformat-truncation=]
snprintf(cStr, buf_size - 1, "%02x", byte);
^~~~~~
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx:47:13: note: 'snprintf' output 3 bytes into a destination of size 2
snprintf(cStr, buf_size - 1, "%02x", byte);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx: In function 'std::__cxx11::string mRichSupport::GetWordHexReprInv(const uint8_t*)':
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx:91:32: warning: 'snprintf' output truncated before the last format character [-Wformat-truncation=]
snprintf(cStr, buf_size - 1, "%02x%02x %02x%02x", byte[0], byte[1], byte[2], byte[3]);
^~~~~~~~~~~~~~~~~~~
/home/cbmdock/cbmroot/fles/mcbm2018/unpacker/CbmMcbm2018UnpackerUtilRich2020.cxx:91:11: note: 'snprintf' output 10 bytes into a destination of size 9
snprintf(cStr, buf_size - 1, "%02x%02x %02x%02x", byte[0], byte[1], byte[2], byte[3]);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The code above assumes that the second snprintf() parameter, "maximal length", is the maximal number of characters one can put in the buffer (which is the buffer length minus 1). But snprintf() considers the second parameter as the full length of the buffer (including the last '\0').
Therefore in all the snprintf() calls above, all the messages are truncated.
I don't know how these messages are used, i.e., if my bugfix changes the results or if it only changes some log output.
Merge request reports
Activity
requested review from @d.smith
assigned to @d.smith
Dear @f.uhlig, @p.-a.loizeau,
you have been identified as code owner of at least one file which was changed with this merge request.
Please check the changes and approve them or request changes.
added CodeOwners label
Should be ok, this is legacy code from the mCBM beamtimes with the previous FPGA board.
The problem here was introduced when @f.uhlig replaced the original deprecated
sprintf
with the safersnprintf
~1 year ago in !1115 (merged) and this stayed since then as nobody maintained it.
Strange thing is that I though we fixed similar warnings in a follow up MR a few months afterward when we realized the range mistake, but the 3 files I re-checked today were not edited afterward. So maybe we will want to check all changes from !1115 (merged)Edited by Pierre-Alain LoizeauThanks @p.-a.loizeau.
@se.gorbunov Please merge (I never worked on the class changed in this MR).
added 2 commits
enabled an automatic merge when the pipeline for 5471d2cd succeeds
added WarnFix label