Hi Andrej,

It does solve the problem of negative values and get rid of searching for index.

However, it still doesn’t help in type casting between enum and other types, and neither longer function/variable names.

Moreover, it won’t be “more convenient” any more, compared to macros for error codes. It may be more complex, considering the additional enum definition structure.

Best regards,

Hu Ziji

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Friday, September 3, 2021 6:00 PM
To: tf-m@lists.trustedfirmware.org
Subject: Re: [TF-M] [RFC] Can we remove the rule to use enum for error code?

Hi,

We can use both approaches (enums, with preset values)

typedef enum <enum_name>{

   <enum_name_1>= -1,

   <enum_name_2> = -2,

   …

} <enum_name>_t;

It solves all mentioned issues.

Thanks,

Andrej Butok

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M
Sent: Friday, September 3, 2021 10:38 AM
To: 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?

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 standard:

• 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 document 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