-
Notifications
You must be signed in to change notification settings - Fork 28
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
Document the new coding style #69
Document the new coding style #69
Conversation
Signed-off-by: Gilles Peskine <[email protected]>
Provide the same amount of information with the same general structure, but adapt the level of detail to what's unusual and what isn't. Signed-off-by: Gilles Peskine <[email protected]>
Signed-off-by: Gilles Peskine <[email protected]>
Signed-off-by: Gilles Peskine <[email protected]>
We're calling the code formatting script code_style, so avoid using the expressions "code style" or "coding style" to mean a different aspect of how the code is written. Signed-off-by: Gilles Peskine <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking pretty good to me, just a couple minor points.
Signed-off-by: Gilles Peskine <[email protected]>
Signed-off-by: Gilles Peskine <[email protected]>
Now that the rule for opening braces isn't a simple "on its own line", discuss the various cases: statements, types, initializers. In particular, for statements, prominently mention the exception for function definitions. Signed-off-by: Gilles Peskine <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for writing the documentation in a way that's both clear, complete and concise!
* Inside parentheses: `if (f(sizeof(int), (int) y))` | ||
* Inside square brackets: `a[i + 1]` | ||
* Before a comma: `f(x, y)` | ||
* After a unary operator: `if (!condition)`, `++x` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* After a unary operator: `if (!condition)`, `++x` | |
* After a prefix unary operator: `if (!condition)`, `++x` |
* Inside square brackets: `a[i + 1]` | ||
* Before a comma: `f(x, y)` | ||
* After a unary operator: `if (!condition)`, `++x` | ||
* Before a unary operator: `x++` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Before a unary operator: `x++` | |
* Before a postfix unary operator: `x++` |
mbedtls_write_thing( void *thing, unsigned char *buf, size_t buflen, | ||
size_t *outlen ); // yes | ||
mbedtls_write_thing(..., unsigned char *buf, size_t *len); // no | ||
mbedtls_write_thing(..., unsigned char *buf, size_t buflen, size_t *outlen); // yes | ||
``` | ||
|
||
For PSA functions, [input buffers](https://armmbed.github.io/mbed-crypto/html/overview/conventions.html#input-buffer-sizes) have a `size_t xxx_size` parameter after the buffer pointer, and [output buffers](https://armmbed.github.io/mbed-crypto/html/overview/conventions.html#output-buffer-sizes) have a `size_t xxx_size` parameter for the buffer size followed by a `size_t *xxx_length` parameter for the output length. This convention is also preferred in new `mbedtls_xxx` code, but older modules often use different conventions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we link to the canonical PSA API pages instead? But maybe that should be a different PR...
The 1.1 specification is at https://arm-software.github.io/psa-api/crypto/1.1/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any update on having a latest
link?
Signed-off-by: Gilles Peskine <[email protected]>
Signed-off-by: Gilles Peskine <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still looks good to me with the changes since my previous review.
Update the coding standards document to the new coding style (including Mbed-TLS/mbedtls#6836).
To be merged at the same time as the new coding style.
Fixes Mbed-TLS/mbedtls#6603.