Hi Michael,
Thanks a lot for the detailed reply. It looks like we all agree to remove this rule, as it was proposed to make code readable.
Regarding the non-portable issue about int32_t return code, imoo, it can be mitigated by making a more simple and well-defined error code system through the project. For example, we can simplify and categorize the TF-M error code as: - PSA standard error code defined in PSA spec. They are error code of PSA interfaces. - TF-M internal error code used in TF-M internal modules. - HAL error code for HAL API, which consists of HW related error code. It is more convenient for developers to select error code, as the scope of their implementation/API in TF-M is clear.
Besides, review process can also help prevent misusing int32_t error code.
I agree that enum can help developers more to prevent misusing the return code. But I'm concerned that it can be difficult to keep a balance between making enum accurate enough and making them simple enough. If enum is recommended, it actually encourages developers to define a dedicated enum for each API layer/module, to make sure the return code is not misused.
Take Initial Attestation service as an example. 4 kinds of enum error code are used in initial attestation, for different modules/layers, without counting in PSA standard error code yet. - enum psa_attest_err_t - enum tfm_plat_err_t - enum attest_token_err_t - enum t_cose_err_t Special functions are defined to map between different enum error codes: psa_status_t <-> psa_attest_err_t, t_cose_err_t <-> attest_token_err_t. Develops shall call those mapping functions frequently to map error codes. Although it is a special example as some enums are from external libraries, I'm not sure if those enums make this service more portable, according to my own experience. They may actually make developers more uncomfortable and confused.
Best regards, Hu Ziji
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Michael Thomas via TF-M Sent: Thursday, September 9, 2021 10:47 PM To: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] TF-M Digest, Vol 35, Issue 6
Ken, Hu, I just saw this message now and wanted to give my perspective based on some of the code Renesas has developed.
In general, the primary benefits of having enums are return codes are type checking and portability. So of you have a top level application using an API that always returns an error from a defined enum list, then the application can switch to using different implementations of the same API and does not have to change its error handling code etc. However, if you are returning uint32 instead then its likely that different implementations of the same API will have any possible return code making the application non-portable.
I think the issue arises when the enum list is not sufficiently well defined so each enum entry ends up acting as a funnel for x number of lower level error code so there is loss of information etc.
But w.r.t the line in the TFM coding guide : " Use enumeration for error codes to keep the code readable.", if the objective is just to make the code readable, then you don’t really need an enum for that... you can achieve readability by using #define XYZ_error. I think that will be much harder to maintain particularly in terms of preventing different error codes from being defined to the same value unless we have a common file where all error code are defined for a specific layer.
-Michael
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of tf-m-request@lists.trustedfirmware.org Sent: Friday, September 3, 2021 4:38 AM To: tf-m@lists.trustedfirmware.org Subject: TF-M Digest, Vol 35, Issue 6
Send TF-M mailing list submissions to tf-m@lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... or, via email, send a message with subject or body 'help' to tf-m-request@lists.trustedfirmware.org
You can reach the person managing the list at tf-m-owner@lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..."
Today's Topics:
1. Re: [RFC] Can we remove the rule to use enum for error code? (Ken Liu) 2. Re: [RFC] Can we remove the rule to use enum for error code? (Andrew Thoelke)
----------------------------------------------------------------------
Message: 1 Date: Fri, 3 Sep 2021 07:54:41 +0000 From: Ken Liu Ken.Liu@arm.com To: "tf-m@lists.trustedfirmware.org" tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] [RFC] Can we remove the rule to use enum for error code? Message-ID: DBBPR08MB4741B0807FC4ACD9F4466520F5CF9@DBBPR08MB4741.eurprd08.prod.outlook.com
Content-Type: text/plain; charset="utf-8"
I am okay to remove it.
Even it can be used to check the error types, but some of the developers do typecast on enum which makes the rule no sense.
/Ken
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu via TF-M Sent: Friday, September 3, 2021 3:45 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] [RFC] Can we remove the rule to use enum for error code?
Hi all,
Probably you didn’t know that there is such a rule in TF-M coding standardhttps://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user-guide.trustedfirmware.org%2Fdocs%2Fcontributing%2Fcoding_guide.html&data=04%7C01%7Cmichael.thomas%40renesas.com%7Cd6b008aa128b4549d14408d96eb63e78%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637662551291203861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X%2BRBFB3swOLUGO3Vi6%2FcjYNiZY6Ka3z9D3sH6vPuPEo%3D&reserved=0:
* Use enumeration for error codes to keep the code readable.
Personally, I’d prefer macros to enum, for error codes.
* The implicit type casting of enum can be an issue in coding. TF-M has a documenthttps://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user-guide.trustedfirmware.org%2Fdocs%2Ftechnical_references%2Fdesign_docs%2Fenum_implicit_casting.html&data=04%7C01%7Cmichael.thomas%40renesas.com%7Cd6b008aa128b4549d14408d96eb63e78%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637662551291203861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NB7XQJXu7nXdv62bWXo4MTIvTSdWI9FhJp2Rlvga19U%3D&reserved=0 to solve this. * Using macros to define error codes aligns with PSA return code definitions. * Enum makes function and variable definitions longer * Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one. * Error codes for errors are usually negative but enums are positive ones by default.
I’d like to propose to remove this rule from TF-M coding standard. But it doesn’t mean that enum shall not be used anymore. I’m wondering if macros for error code in TF-M can be approved as well. 😊
May I know your opinions please? If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot!
Best regards, Hu Ziji -------------- next part -------------- An HTML attachment was scrubbed... URL: https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.trustedfirmware.org%2Fpipermail%2Ftf-m%2Fattachments%2F20210903%2F46ad5cd4%2Fattachment-0001.htm&data=04%7C01%7Cmichael.thomas%40renesas.com%7Cd6b008aa128b4549d14408d96eb63e78%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637662551291203861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W0jrrTMnqCPw1jx8MfesMZkCmpGDXiRUhRo6QYkOfTs%3D&reserved=0
------------------------------
Message: 2 Date: Fri, 3 Sep 2021 08:38:02 +0000 From: Andrew Thoelke Andrew.Thoelke@arm.com To: "tf-m@lists.trustedfirmware.org" tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] [RFC] Can we remove the rule to use enum for error code? Message-ID: DB7PR08MB38651B33CD7BAEB9BF05F0229ACF9@DB7PR08MB3865.eurprd08.prod.outlook.com
Content-Type: text/plain; charset="utf-8"
Hi,
In my experience, the only significant benefit of using enums is that some debuggers display the symbolic name for a value with the enum type.
But, as already mentioned, using enums does not help in parsing logs, or decoding error values in integer variables/registers; particularly when the definition does not provide explicit values for each identifier.
In addition, the rules for determining the implicit integer type for an enum type are non-trivial. This results in a lack of transparency when reading or reviewing code with respect to the size of the enum type in a data structure, or the behaviour when converting an enum value to an integer (or back again).
This is why the PSA specifications use explicitly sized integer types for types like psa_status_t, and macros to define values of such types.
Regards, Andrew
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu via TF-M Sent: 03 September 2021 08:45 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] [RFC] Can we remove the rule to use enum for error code?
Hi all,
Probably you didn’t know that there is such a rule in TF-M coding standardhttps://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user-guide.trustedfirmware.org%2Fdocs%2Fcontributing%2Fcoding_guide.html&data=04%7C01%7Cmichael.thomas%40renesas.com%7Cd6b008aa128b4549d14408d96eb63e78%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637662551291213816%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9ptR1EZNB8CnYEHcJs%2FUnjwSe%2FyayFORj6uS7qo5pvM%3D&reserved=0:
* Use enumeration for error codes to keep the code readable.
Personally, I’d prefer macros to enum, for error codes.
* The implicit type casting of enum can be an issue in coding. TF-M has a documenthttps://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user-guide.trustedfirmware.org%2Fdocs%2Ftechnical_references%2Fdesign_docs%2Fenum_implicit_casting.html&data=04%7C01%7Cmichael.thomas%40renesas.com%7Cd6b008aa128b4549d14408d96eb63e78%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637662551291213816%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RVgoiRNQAtJHmNavso9EStJ82SLc84hyXX8K%2F67MPps%3D&reserved=0 to solve this. * Using macros to define error codes aligns with PSA return code definitions. * Enum makes function and variable definitions longer * Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one. * Error codes for errors are usually negative but enums are positive ones by default.
I’d like to propose to remove this rule from TF-M coding standard. But it doesn’t mean that enum shall not be used anymore. I’m wondering if macros for error code in TF-M can be approved as well. 😊
May I know your opinions please? If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot!
Best regards, Hu Ziji -------------- next part -------------- An HTML attachment was scrubbed... URL: https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.trustedfirmware.org%2Fpipermail%2Ftf-m%2Fattachments%2F20210903%2F5b23ddf5%2Fattachment.htm&data=04%7C01%7Cmichael.thomas%40renesas.com%7Cd6b008aa128b4549d14408d96eb63e78%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637662551291213816%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ini2TxEOPSBAPhKy3ZSdE2qT%2F3dIOg7%2F7%2BCyzZH%2FeQ0%3D&reserved=0
------------------------------
Subject: Digest Footer
TF-M mailing list TF-M@lists.trustedfirmware.org https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...
------------------------------
End of TF-M Digest, Vol 35, Issue 6 ***********************************
Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not an intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you.