You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
libcanard exposes a configurable assertion macro: CANARD_ASSERT(x) (defaulting to assert(x)), which can be redefined via -DCANARD_CONFIG_HEADER="..." without touching library source.
The cy core library, cy_can.c, and platform backends like cy_can_socketcan.c do not follow this pattern and call the plain standard assert() directly, with no CY_ASSERT (or similar) indirection macro and no config-header hook.
On embedded/baremetal targets, applications frequently need custom assertion handling (e.g., trigger a fault handler, blink an LED, log via a specific channel) and this makes it impossible to use the library without modifying its source code, which is undesirable.
I am not a big fan of config headers but in this case we might actually need one because sometimes it is impossible to override a function-like macro through -D parameters (e.g., in CMake). It would be like:
I think its inclusion and the CY_ASSERT definition belong in the cy_platform.h header because the application has no use for it, unlike the platform glue libraries (cy_can, cy_udp_posix).
While we're at it, it might make sense to move CY_CONFIG_TRACE/CY_TRACE from cy.h into cy_platform.h because it is not really related to the library API, and it must appear after the config header inclusion.
One module which uses assert(), namely udp_wrapper works as a standalone file without depending on cy. Is it ok if I make it include cy_platform.h header?
@pavel-kirienko Unfortunately, defining the CY_ASSERT macro inside cy_platform.h creates a circular dependency between cy.h and cy_plaform.h. (check #72)
Activity
pavel-kirienko commentedon Jul 20, 2026
A PR replacing bare asserts with CY_ASSERT would be accepted. CY_ASSERT should default to the plain assert unless overridden.
bjsowa commentedon Jul 22, 2026
@pavel-kirienko Should CY_ASSERT be defined in each
.cfile or in a common header file (e.g.cy.h)? What aboutCY_CONFIG_HEADER?pavel-kirienko commentedon Jul 22, 2026
I am not a big fan of config headers but in this case we might actually need one because sometimes it is impossible to override a function-like macro through
-Dparameters (e.g., in CMake). It would be like:I think its inclusion and the CY_ASSERT definition belong in the
cy_platform.hheader because the application has no use for it, unlike the platform glue libraries (cy_can, cy_udp_posix).While we're at it, it might make sense to move
CY_CONFIG_TRACE/CY_TRACEfrom cy.h into cy_platform.h because it is not really related to the library API, and it must appear after the config header inclusion.Does that make sense?
bjsowa commentedon Jul 22, 2026
One module which uses
assert(), namelyudp_wrapperworks as a standalone file without depending on cy. Is it ok if I make it includecy_platform.hheader?pavel-kirienko commentedon Jul 22, 2026
Let's remove those two asserts, they are low-value and not worth introducing the Cy dependency.
bjsowa commentedon Jul 23, 2026
@pavel-kirienko Unfortunately, defining the CY_ASSERT macro inside
cy_platform.hcreates a circular dependency betweency.handcy_plaform.h. (check #72)pavel-kirienko commentedon Jul 24, 2026
Yeah I just left my review there, seems like we'll need to move this into cy.h