From 4210739d9128fc9db4a360bb1e818592985f5e7e Mon Sep 17 00:00:00 2001
From: wjcloudy <56305354+wjcloudy@users.noreply.github.com>
Date: Sat, 20 Jun 2026 21:23:53 +0100
Subject: [PATCH] canhardware: drop unused bool overload from 2-arg Send to fix
 ambiguity

The forceExt-defaulted 2-arg convenience
  void Send(uint32_t canId, uint32_t data[2], bool forceExt = false)
makes a 3-arg call Send(id, uint32_t* data, intLen) ambiguous: the int
length matches both this (int->bool) and the length overload
(int->uint8_t), so callers must cast the length to uint8_t.

Nothing passes forceExt through this 2-arg form - within libopeninv it is
carried via the canId CAN_FORCE_EXTENDED bit, and all internal Send calls
use the 2-arg or uint8_t-length forms. Drop the bool: Send(id, data)
still sends 8 bytes, forceExt stays available via the 4-arg
Send(id, data, len, true), and Send(id, u32buf, len) now resolves
unambiguously to the length overload - no uint8_t cast needed.
---
 include/canhardware.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/canhardware.h b/include/canhardware.h
index 9273bef..a4b7b19 100644
--- a/include/canhardware.h
+++ b/include/canhardware.h
@@ -58,7 +58,7 @@ class CanHardware
 
       CanHardware();
       virtual void SetBaudrate(enum baudrates baudrate) = 0;
-      void Send(uint32_t canId, uint32_t data[2], bool forceExt = false) { Send(canId, data, 8, forceExt); }
+      void Send(uint32_t canId, uint32_t data[2]) { Send(canId, data, 8); }
       void Send(uint32_t canId, uint8_t data[8], uint8_t len, bool forceExt = false) { Send(canId, (uint32_t*)data, len, forceExt); }
       virtual void Send(uint32_t canId, uint32_t data[2], uint8_t len, bool forceExt = false) = 0;
       void HandleRx(uint32_t canId, uint32_t data[2], uint8_t dlc);