capi: allow printing calls on stderr

[VDanielEdwards]

Subject

Exploring how to 'log' / 'trace' / ... C-API calls. This just prints the arguments and some results / errors on stderr.

This is not meant to be merged (as-is). It just exists as a ground for discussion and to explore any issues that might arise.

Notes and issues:

• How do we deal with any pointer-to-struct type arguments (e.g., SilKit_CanFrame *)?

  • Access to struct fields isn't safe until the struct header has been verified
  • Acessing struct fields that don't exist (because the caller was compiled against an older header version) will generally lead to a crash

• How do we deal with returns and the out-pointers?

  • Do we care about the return code in the API tracing or do we just trace the arguments?
  • Do we care about the values assigned to the out-arguments?

Example Output

From SilKitCanReader:

{"thread":48872,"func":"SilKit_CanController_Create","data":"0x1fcce72aa60 \"CanController1\" \"CAN1\""}
{"thread":48872,"func":"SilKit_CanController_Create","data":"0x1fcceabb6d0"}
{"thread":48872,"func":"SilKit_CanController_AddFrameHandler","data":"0x1fcceabb6d0 0x1fccea71540 0x7ff7801b682a 2 0x62fa7cf698"}
{"thread":48872,"func":"SilKit_CanController_AddFrameHandler","data":"0"}
{"thread":53488,"func":"SilKit_CanController_SetBaudRate","data":"0x1fcceabb6d0 10000 1000000 2000000"}
{"thread":53488,"func":"SilKit_CanController_Start","data":"0x1fcceabb6d0"}

From SilKitCanWriter:

{"thread":28152,"func":"SilKit_CanController_Create","data":"0x260db29e530 \"CanController1\" \"CAN1\""}
{"thread":28152,"func":"SilKit_CanController_Create","data":"0x260db603490"}
{"thread":28152,"func":"SilKit_CanController_AddFrameHandler","data":"0x260db603490 0x260db225d60 0x7ff69b54680c 2 0x7656cff1f8"}
{"thread":28152,"func":"SilKit_CanController_AddFrameHandler","data":"0"}
{"thread":40316,"func":"SilKit_CanController_SetBaudRate","data":"0x260db603490 10000 1000000 2000000"}
{"thread":40316,"func":"SilKit_CanController_Start","data":"0x260db603490"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}
{"thread":40316,"func":"SilKit_CanController_SendFrame","data":"0x260db603490 0x76571fe610 0x0"}

[VDanielEdwards]

Since the 'textual' version of a std::thread::id isn't neccessarily a number this could produce invalid JSON. Just keep that in mind.

[MariusBgm]

Yeah, the possible struct version mismatch is a real ABI nightmare. i need to digest this a bit, and play around with it

[MariusBgm]

func is an implementation defined string, so the traces are tied to the current OS/compiler.
std::source_location would be nice...

[VDanielEdwards]

__func__ is actually standard C99. For functions with C linkage (like the C-API) it is also consistently the function name. See cppreference.