Hello, There are multiple occurrences in TFA Code where assert statements are used to handle function arguments. But these assert statements are currently enabled only in debug mode. So, I wanted to know that will there be any harm in continuing to use assert statements in production code as well for handling failures?
Regards, Nithin S
Hello Nithin,
If you have not already done it, I suggest you take a look at TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines...
This document clarifies what we consider as programming errors. Some might be surprising (e.g. bad argument provided by platform porting function), if you're coming from a different project with a different error handling policy. Programming errors can be safely handled through debug assertions and removed in debug builds.
All other types of errors must be handled with proper runtime tests which are preserved in release builds.
Hope that helps, Sandrine ________________________________ From: Nithin S via TF-A tf-a@lists.trustedfirmware.org Sent: 11 October 2023 09:36 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Usage of assert functions in TFA Code
Hello, There are multiple occurrences in TFA Code where assert statements are used to handle function arguments. But these assert statements are currently enabled only in debug mode. So, I wanted to know that will there be any harm in continuing to use assert statements in production code as well for handling failures?
Regards, Nithin S -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
Hi Sandrine ,
Programming errors can be safely handled through debug assertions and removed in debug builds.
Programming errors (eg bad argument) should be caught in release build also right . If somehow the programming errors occur in release build, how these will be caught in release build ? Why is the policy to handle programming error in debug builds only.
Regards Amit
From: Sandrine Bailleux via TF-A tf-a@lists.trustedfirmware.org Sent: Wednesday, October 11, 2023 1:52 PM To: tf-a@lists.trustedfirmware.org; Nithin S nithinrocks08@gmail.com Subject: [TF-A] Re: Usage of assert functions in TFA Code
Hello Nithin,
If you have not already done it, I suggest you take a look at TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines...
This document clarifies what we consider as programming errors. Some might be surprising (e.g. bad argument provided by platform porting function), if you're coming from a different project with a different error handling policy. Programming errors can be safely handled through debug assertions and removed in debug builds.
All other types of errors must be handled with proper runtime tests which are preserved in release builds.
Hope that helps, Sandrine ________________________________________ From: Nithin S via TF-A mailto:tf-a@lists.trustedfirmware.org Sent: 11 October 2023 09:36 To: mailto:tf-a@lists.trustedfirmware.org mailto:tf-a@lists.trustedfirmware.org Subject: [TF-A] Usage of assert functions in TFA Code Hello, There are multiple occurrences in TFA Code where assert statements are used to handle function arguments. But these assert statements are currently enabled only in debug mode. So, I wanted to know that will there be any harm in continuing to use assert statements in production code as well for handling failures?
Regards, Nithin S
Hi Amit,
In TF-A project, the expectation is that all programming errors would be caught and fixed during development and testing, prior to product shipping. This is why the policy says that it's safe to remove them in release builds. This is the default behaviour. However, if this policy does not suit your use case, it is possible to retain assertions in release builds by building TF-A source code with ENABLE_ASSERTIONS=1. This will override the default behaviour.
Best regards, Sandrine
________________________________ From: Nagal, Amit amit.nagal@amd.com Sent: 11 October 2023 11:57 To: Sandrine Bailleux Sandrine.Bailleux@arm.com; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org; Nithin S nithinrocks08@gmail.com Subject: RE: [TF-A] Re: Usage of assert functions in TFA Code
Hi Sandrine ,
Programming errors can be safely handled through debug assertions and removed in debug builds.
Programming errors (eg bad argument) should be caught in release build also right . If somehow the programming errors occur in release build, how these will be caught in release build ? Why is the policy to handle programming error in debug builds only.
Regards Amit
From: Sandrine Bailleux via TF-A tf-a@lists.trustedfirmware.org Sent: Wednesday, October 11, 2023 1:52 PM To: tf-a@lists.trustedfirmware.org; Nithin S nithinrocks08@gmail.com Subject: [TF-A] Re: Usage of assert functions in TFA Code
Hello Nithin,
If you have not already done it, I suggest you take a look at TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines...
This document clarifies what we consider as programming errors. Some might be surprising (e.g. bad argument provided by platform porting function), if you're coming from a different project with a different error handling policy. Programming errors can be safely handled through debug assertions and removed in debug builds.
All other types of errors must be handled with proper runtime tests which are preserved in release builds.
Hope that helps, Sandrine ________________________________________ From: Nithin S via TF-A mailto:tf-a@lists.trustedfirmware.org Sent: 11 October 2023 09:36 To: mailto:tf-a@lists.trustedfirmware.org mailto:tf-a@lists.trustedfirmware.org Subject: [TF-A] Usage of assert functions in TFA Code
Hello, There are multiple occurrences in TFA Code where assert statements are used to handle function arguments. But these assert statements are currently enabled only in debug mode. So, I wanted to know that will there be any harm in continuing to use assert statements in production code as well for handling failures?
Regards, Nithin S -- TF-A mailing list -- mailto:tf-a@lists.trustedfirmware.org To unsubscribe send an email to mailto:tf-a-leave@lists.trustedfirmware.org
tf-a@lists.trustedfirmware.org
-
Nagal, Amit -
Nithin S -
Sandrine Bailleux