Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove double underscores from macro and add a check for it #230

Merged
merged 2 commits into from
Aug 21, 2019

Conversation

AndrzejKurek
Copy link
Contributor

This PR addresses issue #171.
It removes the double underscore from a macro, adds an exception for it in "test_psa_constant_names", and introduces a check for double underscores in check-names.sh.

This pattern (identifiers containing a double underscore anywhere in them)
is reserved.
Copy link
Contributor

@Patater Patater left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Check names commit should also go to Mbed TLS development branch (no other ports needed)

@Patater Patater added the bug Something isn't working label Aug 21, 2019
Copy link
Contributor

@dgreen-arm dgreen-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dgreen-arm dgreen-arm merged commit ecfd050 into ARMmbed:development Aug 21, 2019
@athoelke
Copy link
Contributor

This will now result in PSA_ALG_AEAD_WITH_DEFAULT_TAG_LENGTH_CASE appearing in the PSA Crypto specification as all symbols that begin with PSA_ALG_ are considered part of the architectural specification rather than part of the mbed implementation that should not be part of the interface spec.

Although we could fix this with a matching change to the tools that extracts the spec documentation from the mbed implementation (which we still do for the moment), it is not an ideal situation.

Ideally, there needs to be some reserved name spaces defined for the PSA specification, such that implementations would be able to allocate symbols for their own internal and extension APIs without risk of collision with the specification. It may be late to request that mbed not use a psa_ or PSA_ prefix for its own APIs - although that is likely to be what that specs will recommend to avoid clashes with future version of the specification.

@gilles-peskine-arm
Copy link
Collaborator

Ideally, there needs to be some reserved name spaces defined for the PSA specification, such that implementations would be able to allocate symbols for their own internal and extension APIs without risk of collision with the specification.

I agree. Does the PSA framework define this?

It may be late to request that mbed not use a psa_ or PSA_ prefix for its own APIs - although that is likely to be what that specs will recommend to avoid clashes with future version of the specification.

We've been inconsistent about this. The first time I added an implementation-specific function to Mbed Crypto, I called it mbedtls_psa_xxx. But then I didn't follow this convention for other implementation-specific functions which I considered to be experimental, possibly to be made official at a later date. For macros, I never used MBEDTLS_PSA_xxx because Mbed Crypto has a very fragile script that checks for possible typos in preprocessor symbols that begin with MBEDTLS_ and I wanted to minimize PSA-related modifications, but I think now we can move past that (#241).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants