<div dir="ltr">OOH.. nice one. I had missed that in my template implementation.  I'm a big fan of using C++ templating to do type-safe versions of this kind of stuff...   This is my template version:<br><div>/** Sign extend an unsigned to a signed integer of the same size.<br> */<br>template<typename UINT, typename INT, uint8_t SIGNBIT><br>INT sign_extend( UINT uvalue)<br>{<br>  typedef typename std::make_unsigned<INT>::type uint_t;<br>  uint_t newuvalue = uvalue;<br>  if ( newuvalue & ( UINT(1U) << SIGNBIT) ) {<br>    newuvalue |= ~((uint_t(1U) << SIGNBIT) - 1);<br>  }<br>  return reinterpret_cast<INT &>(uvalue);<br>}<br>It could probably be converted into a version that would infer some of the types.. but this should work pretty well and should compile down to close to the same code.</div><div>Usage from my code: Where BYTES is a templated integer value parameter.</div><div> res = sign_extend < uint32_t, int32_t, BYTES * 8 - 1 > (ures);<br></div><div><br></div><div>I also have a templated buffer extractor that allows for checking available space!</div><div>For example this code (which extracts 2 bytes as a signed integer), which should now work with sign extension thanks to your bugfix and the above templated version of sign extension:</div><div><br></div>         int32_t signedValue;<br>         if (!can_buff_int<2>(data, 10, signedValue )) {<br>           ESP_LOGE(TAG, "IoniqISOTP.BMC: BMS Current: Bad Buffer");<br>         } else {<br>           StdMetrics.ms_v_bat_current->SetValue((float)signedValue / 10.0, Amps);<br><div>         } </div><div><br></div><div>//.ichael</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 14 Oct 2022 at 05:35, Ludovic LANGE <<a href="mailto:ll-ovmsdev@lange.nom.fr">ll-ovmsdev@lange.nom.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  

    
  
  <div>
    <p>Dear list,</p>
    <p>I've come across an issue with the DBC parser where a non-32-bit
      negative number was incorrectly decoded.</p>
    <p>I've traced this to an issue with sign-extension ; and I've
      proposed a fix here
<a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/736" target="_blank">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/736</a></p>
    <p>Before having it merged, I'd like to gather some feedback from
      users of the DBC module.</p>
    <p>Please have a look, and comment directly on the GitHub PR.</p>
    <p>Thanks in advance !</p>
    <p>Regards,</p>
    <p>Ludovic<br>
    </p>
    <div id="m_-1913493134659603489grammalecte_menu_main_button_shadow_host" style="width:0px;height:0px"></div>
  </div>

_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div>