Proposal: Introduce ZSERIO_FOR_FUNCTIONAL_SAFETY Define for Enhanced Safety Compliance

[MisterGC]

To align zserio’s C++17 support with functional safety requirements, I propose introducing a ZSERIO_FOR_FUNCTIONAL_SAFETY define. This define would conditionally disable API elements that prioritize usability over strict validation and safety compliance (e.g., convenience overloads, unchecked operations). The goal is to create a clear distinction between safety-critical and general-purpose use cases, making the library more versatile for projects with strict safety demands.

This approach would also allow us to provide very accessible APIs for users operating in non-critical scenarios without compromising usability. At the same time, it would eliminate the need for safety-critical users to define exceptions or implement their own mechanisms to remove/disable non-compliant features, streamlining the development process.

I’d love to hear thoughts on:

• Feasibility of this approach
• Impact on usability and maintenance
• Potential use cases or alternative solutions

Looking forward to your feedback!

[mikir]

I think the main problem will be the magnitude of the differences between critical safety and user friendly versions. We should identify all of them before some solution is taken.

If there are differencies only in the runtime library, this solution would be feasible without any big complications for the further maintenance.

But if there are a lot differencies in the generated code, this solution could significantly complicate implementation, testing and maintenance.