From 9fe58c0f290f980c9a195d0859716e3bf94601df Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Thu, 22 Dec 2022 22:05:15 +0100 Subject: [PATCH 01/10] Fix indentation and spelling of defined Signed-off-by: Gilles Peskine --- kb/development/mbedtls-coding-standards.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index c71ec6d7..3117db83 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -125,9 +125,9 @@ Exceptions: you can and omit the trailing comma in structure initializers that f When using preprocessor directives to enable or disable parts of the code, use `#if defined` instead of `#ifdef`. Add a comment to the `#endif` directive if the distance to the opening directive is bigger than a few lines or contains other directives: ```c - #if define(MBEDTLS_HAVE_FEATURE) - /* ten lines of code or other directives */ - #endif /* MBEDTLS_HAVE_FEATURE */ +#if defined(MBEDTLS_HAVE_FEATURE) +/* ten lines of code or other directives */ +#endif /* MBEDTLS_HAVE_FEATURE */ ``` ## Naming conventions From daf729c2cd67bdb6402f26a62b4013209058f624 Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Thu, 22 Dec 2022 22:21:54 +0100 Subject: [PATCH 02/10] Switch the "code formatting" section to the new style 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 --- kb/development/mbedtls-coding-standards.md | 140 ++++++++++----------- 1 file changed, 69 insertions(+), 71 deletions(-) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index 3117db83..ca791b62 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -8,102 +8,101 @@ This document describes Mbed TLS preferences for code formatting, naming convent ## Code Formatting -Mbed TLS source code files use 4 spaces for indentation, **not tabs**, with a preferred maximum line length of 80 characters. +### K&R -Every code statement should be on its own line. +Mbed TLS generally follows the style of *The C Programming Language*, Second Edition, 1988, by Brian Kernighan and Dennis Ritchie (“K&R2”). The main deviations are: -**Avoid statements like this:** -```c - if( a == 1 ) { b = 1; do_function( b ); } - if( a == 1 ) do_function( a ); -``` +* Indentation is 4 spaces (like K&R2, not 5 spaces like K&R1). Do not use tabs. +* `case` is indented one level further than `switch`. +* The body of `if`, `for` or `while` must be on a separate line and surrounded with braces, even if it's a single statement. -### Space placement +### Indentation -Mbed TLS uses a non-standard space placement throughout the code, where there is no space between a function name and all parentheses are separated by one space from their content: -```c - if( ( ret = demo_function( a, b, c ) ) != 0 ) -``` -The same applies to function definitions: -```c - int demo_function( int a, const unsigned char *value, size_t len ) -``` -There are a few exceptions to this rule. This includes the preprocessor directive `defined` and casts, as well as arguments for function-like macros: -```c - #if defined(MBEDTLS_HAVE_TIME) - timestamp = (uint32_t) time( NULL ); -``` +Mbed TLS source code files use 4 spaces for indentation, **not tabs**, with a preferred maximum line length of 80 characters. -### Braces placement and block declaration +`case` is indented one level further than `switch`. -Braces (curly brackets) should be located on a line by themselves at the indentation level of the original block: -```c - if( val >= 1 ) - { - if( val == 1 ) - { - /* code block here */ - } - else - { - /* alternate code block */ - } - } -``` -In case a block is only single source code line, the braces can be omitted if the block initiator is only a single line: ```c - if( val >= 1 ) - a = 2; +switch (x) { + case 0: + zero(); + break; + ... +} ``` -But not if it is a multi-line initiator: + +Labels are indented at the same level as the enclosing block. ```c - if( val >= 1 && - this_big_statement_deserved_its_own_line == another_big_part ) - { - a = 2; +int f() +{ + ...code... + if (ret != 0) { + goto exit; } + ...code... +exit: + ...cleanup... + return ret; +} ``` -### Related lines: Multi-line formatting and indentation +Every code statement should be on its own line, except in `for` loop headers. -Multiple related source code lines should be formatted to be easily readable: -```c -#define GET_UINT32_LE( n, b, i ) \ -{ \ - (n) = ( (uint32_t) (b)[(i) ] ) \ - | ( (uint32_t) (b)[(i) + 1] << 8 ) \ - | ( (uint32_t) (b)[(i) + 2] << 16 ) \ - | ( (uint32_t) (b)[(i) + 3] << 24 ); \ -} +### Space placement -if( my_super_var == second_super_var && - this_check_will_do != the_other_value ) +Put a space in the following places: -do_function( ctx, this_is_a_value, value_b, - the_special_var ); +* Around binary operators: `(x + y) * z` +* After a comma: `f(x, y)` +* Before the asterisk in a pointer type: `int *p` +* Between `if`, `switch`, `while`, `for` and the opening parenthesis: `if (f(x))` +* Outside curly braces: `do { ... } while (!done)`, `struct mystruct s = { 0 }` +* Inside the curly braces around initializers: `int a[] = { 1, 2, 3 };` -void this_is_a_function( context_struct *ctx, size_t length, - unsigned char *result ); -``` +Do not put a space in the following places: -### Extra parentheses for `return` and `sizeof` +* After the function or macro name in a function or macro call: `f(x, y)` +* 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` +* Before a unary operator: `x++` +* Between an array and the following opening bracket: `int a[2]; a[i]` +* Around field access symbols: `s.a`, `p->a` +* After the asterisk in a pointer type: `int *p` +* Between the asterisks double pointers types or derefences: `char **p`, `x + **p` -Within Mbed TLS return statements use parentheses to contain their value: +### Use of parentheses + +`sizeof` expressions always use parentheses even when it is not necessary (when taking the size of an object): ```c - return( 0 ); + memset(buf, 0, sizeof(buf)); ``` -Similarly, sizeof expressions always use parentheses even when it is not necessary (when taking the size of an object): + +### Braces placement and block declaration + +Braces are mandatory in control statements such as `if`, `while`, `for`, even when the content is a simple statement. +Opening braces (curly brackets) are on the same line as the control statement. + +Closing braces are aligned with the control statement or opening brace. They are generally alone on their line, except when followed by `else` or by the `while` of a `do ... while` statement. + ```c - memset( buf, 0, sizeof( buf ) ); + do { + x += f(); + if (x == 0) { + continue; + } + x += g(); + } while (condition); ``` ### Formatting of lists When a function or macro call doesn't fit on a single line, put one argument per line or a sensible grouping per line. For example, in the snippet below, `input_buffer` and `input_size` are on a line of their own even though the call could fit on two lines instead of three if they were separated: ```c - function_with_a_very_long_name( parameter1, parameter2, - input_buffer, input_size, - output_buffer, output_size ); + function_with_a_very_long_name(parameter1, parameter2, + input_buffer, input_size, + output_buffer, output_size); ``` Lists of items other than function arguments should generally have one item per line. Exceptions: @@ -113,8 +112,7 @@ Lists of items other than function arguments should generally have one item per In lists of items such array initializers and enum definitions, do include the optional comma after the last element. This simplifies merging, reordering, etc. ```c -typedef enum foo -{ +typedef enum foo { FOO_1, FOO_2, // <- do put a comma here } From efca62be3eddd8156e3d7c8b93b45facea114404 Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Thu, 22 Dec 2022 22:29:09 +0100 Subject: [PATCH 03/10] Adjust coding style in examples Signed-off-by: Gilles Peskine --- kb/development/mbedtls-coding-standards.md | 68 +++++++++++----------- 1 file changed, 33 insertions(+), 35 deletions(-) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index ca791b62..a37f32fc 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -183,12 +183,12 @@ This section applies fully to classic `mbedtls_xxx()` APIs and mostly to the new If a module uses a context structure for passing around its state, the module should contain an `init()` and `free()` function, with the module or context name prepended to it. The `init()` function must always return `void`. If some initialization must be done that may fail (such as allocating memory), it should be done in a separate function, usually called `setup()`. The `free()` function must free any allocated memory within the context, but not the context itself. It must set to zero any data in the context or substructures: ```c mbedtls_cipher_context_t ctx; - mbedtls_cipher_init( &ctx ); - ret = mbedtls_cipher_setup( &ctx, ... ); + mbedtls_cipher_init(&ctx); + ret = mbedtls_cipher_setup(&ctx, ...); /* Check ret, goto cleanup on error */ /* Do things, goto cleanup on error */ cleanup: - mbedtls_cipher_free( &ctx ); + mbedtls_cipher_free(&ctx); ``` The goal of separating the `init()` and `setup()` part is that if you have multiple contexts, you can call all the `init()` functions first and then all contexts are ready to be passed to the `free()` function in case an error happens in one of the `setup()` functions or elsewhere. @@ -208,18 +208,17 @@ Most functions should return `int`, more specifically `0` on success (the operat Function should avoid in-out parameters for length (multiplexing buffer size on entry with length used/written on exit) since they tend to impair readability. For example: ```c - mbedtls_write_thing( void *thing, unsigned char *buf, size_t *len ); // no - 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. You can use in-out parameters for functions that receive a pointer to some buffer, and update it after parsing from or writing to that buffer: ```c - mbedtls_asn1_get_int( unsigned char **p, - const unsigned char *end, - int *value ); +mbedtls_asn1_get_int(unsigned char **p, + const unsigned char *end, + int *value); ``` In that case, the `end` argument should always point to one past the one of the buffer on entry. @@ -229,7 +228,7 @@ Also, contexts are usually in-out parameters, which is acceptable. Function declarations should keep `const` correctness in mind when declaring function arguments. Arguments that are pointers and are *not* changed by the functions should be marked as such: ```c - int do_calc_length( const unsigned char *str ) +int do_calc_length(const unsigned char *str); ``` ## Coding style @@ -284,47 +283,47 @@ static char self_test_key = { This is acceptable, but deprecated: ```c - if( + if ( #if defined(MBEDTLS_USE_PSA_CRYPTO) - psa_condition( ) + psa_condition() #else - legacy_condition( ) + legacy_condition() #endif ) - do_stuff( ); + do_stuff(); ``` Such code is generally more readable with an intermediate variable, thus the following style is preferred: ```c #if defined(MBEDTLS_USE_PSA_CRYPTO) - const int want_stuff = psa_condition( ); + const int want_stuff = psa_condition(); #else - const int want_stuff = legacy_condition( ); + const int want_stuff = legacy_condition(); #endif - if( want_stuff ) - do_stuff( ); + if (want_stuff) + do_stuff(); ``` Do not put partial instructions in a conditionally compiled span. For example, do not write the code above like this: ```c #if defined(MBEDTLS_USE_PSA_CRYPTO) // NO! - if( psa_condition( ) ) // NO! + if (psa_condition()) // NO! #else // NO! - if( legacy_condition( ) ) // NO! + if (legacy_condition()) // NO! #endif // NO! - do_stuff( ); // NO! + do_stuff(); // NO! ``` Having two instances of `if` in the source code, but only one actually compiled, is confusing both for humans and for tools such as indenters and linters. Exception: the following idiom, with a chain of if-else-if statements, is accepted. ```c #if defined(MBEDTLS_FOO) - if( is_a_foo( type ) ) - process_foo( type, data ); + if (is_a_foo(type)) + process_foo(type, data); else #endif /* MBEDTLS_FOO */ #if defined(MBEDTLS_BAR) - if( is_a_bar( type ) ) - process_bar( type, data ); + if (is_a_bar(type)) + process_bar(type, data); else #endif /* MBEDTLS_BAR */ { @@ -342,26 +341,25 @@ If possible, use the C core language rather than macros. For example, if an expr ### Macro definition hygiene -When the code contains a macro call `MBEDTLS_FOO( x, y )`, it should behave as much as possible as if `MBEDTLS_FOO` was a function. Deviate from this only to the extent necessary to make the macro practical. +When the code contains a macro call `MBEDTLS_FOO(x, y)`, it should behave as much as possible as if `MBEDTLS_FOO` was a function. Deviate from this only to the extent necessary to make the macro practical. If the arguments of a macro are C expressions (they usually are), put parentheses around the argument in the expansion. For example: ```c -#define FOO_SIZE( bits ) ( ( (bits) + 7 ) / 8 + 4 ) +#define FOO_SIZE(bits) (((bits) + 7) / 8 + 4) ``` -The expansion contains `( (bits) + 7 )`, not `bits + 7`, so that a call like `FOO_SIZE( x << 3 )` is parsed correctly. As an exception, it's ok to omit parentheses if the argument is directly passed to a function argument (or comma operator): `#define A( x ) f( x, 0 )` is acceptable. +The expansion contains `((bits) + 7)`, not `bits + 7`, so that a call like `FOO_SIZE(x << 3)` is parsed correctly. As an exception, it's ok to omit parentheses if the argument is directly passed to a function argument (or comma operator): `#define A(x) f(x, 0)` is acceptable. -If the expansion of a macro is a C expression, put parentheses around the expansion. Continuing the example above, this is so that a call like `FOO_SIZE( x ) * 2` is parsed correctly. As an exception, it's ok to omit parentheses if the expansion is a function call or other highest-precedence operator: `#define A( x ) f( x, 0 )` is acceptable. +If the expansion of a macro is a C expression, put parentheses around the expansion. Continuing the example above, this is so that a call like `FOO_SIZE(x) * 2` is parsed correctly. As an exception, it's ok to omit parentheses if the expansion is a function call or other highest-precedence operator: `#define A(x) f(x, 0)` is acceptable. -If a macro expands to a statement, wrap it in `do { ... } while( 0 )` so that it can be used in contexts that expect a single statement. For example: +If a macro expands to a statement, wrap it in `do { ... } while (0)` so that it can be used in contexts that expect a single statement. For example: ```c #define MBEDTLS_MPI_CHK(f) \ - do \ - { \ - if( ( ret = (f) ) != 0 ) \ + do { \ + if ((ret = (f)) != 0) \ goto cleanup; \ - } while( 0 )` + } while (0)` ``` -The expansion is not just `if( ( ret = (f) ) != 0 ) goto cleanup` because that would not work in a context like `if( condition ) MBEDTLS_MPI_CHK( f( ) ); else ++x;` (the `else` would get attached to the wrong `if`). +The expansion is not just `if ((ret = (f)) != 0) goto cleanup` because that would not work in a context like `if (condition) MBEDTLS_MPI_CHK(f()); else ++x;` (the `else` would get attached to the wrong `if`). Follow the expression paradigm or the statement paradigm if possible. Other paradigms are permitted if necessary, for example a macro that expands to an initializer such as ```c From 0dd8840ea34d3b2d2ce29256108ef14d97849669 Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Thu, 22 Dec 2022 22:29:21 +0100 Subject: [PATCH 04/10] Document enforcement with uncrustify Signed-off-by: Gilles Peskine --- kb/development/mbedtls-coding-standards.md | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index a37f32fc..175d1ba1 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -8,6 +8,43 @@ This document describes Mbed TLS preferences for code formatting, naming convent ## Code Formatting +### Enforcement with uncrustify + +In order to maintain a consistent coding style, the C code in Mbed TLS is formatted with [Uncrustify](https://github.com/uncrustify/uncrustify). The reference version of Uncrustify is 0.75.1; older or newer versions may give different results. + +#### Code style check script + +A test on the continuous integration systems verifies that the C code has the expected style. The script [`scripts/code_style.py`](https://github.com/Mbed-TLS/mbedtls/blob/development/scripts/code_style.py) can check or fix the coding style. + +To check that the coding style is correct (for example before submitting a pull request): +```sh +scripts/code_style.py +``` + +To enforce the coding style on specific files: +```sh +scripts/code_style.py --fix library/file_i_edited.c tests/suites/test_suite_i_also_edited.function +``` + +To enforce the coding style on all files checked into Git: +```sh +scripts/code_style.py --fix library/file_i_edited.c tests/suites/test_suite_i_also_edited.function +``` + +#### Exceptions to enforcement + +The automatic tool usually does a good job of making the code presentable, but it can sometimes make mistakes. It is possible to disable enforcement for a fragment of code by placing it between comments containing `*INDENT-OFF*` and `*INDENT-ON*` (despite the name, this controls all style enforcement, not just indentation). Do this only in egregious cases. + +```c + // normal code here +/* *INDENT-OFF* */ + // weird code here +/* *INDENT-ON* */ + // normal code here +``` + +Code in the `3rdparty` directory generally retains its original style, and is not subject to enforcement. + ### K&R Mbed TLS generally follows the style of *The C Programming Language*, Second Edition, 1988, by Brian Kernighan and Dennis Ritchie (“K&R2”). The main deviations are: From 99b42389d049d6f47492b0fa4339ec51c08ff35f Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Thu, 22 Dec 2022 22:30:27 +0100 Subject: [PATCH 05/10] Reserve "coding style" to formatting 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 --- kb/development/mbedtls-coding-standards.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index 175d1ba1..00613fd3 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -268,7 +268,7 @@ Function declarations should keep `const` correctness in mind when declaring fun int do_calc_length(const unsigned char *str); ``` -## Coding style +## Code structure ### ISO C99 From 04f89115c05a1b900f2fdfbc9b79c4ae1d156ecf Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Fri, 23 Dec 2022 11:01:28 +0100 Subject: [PATCH 06/10] Fix copypasta Signed-off-by: Gilles Peskine --- kb/development/mbedtls-coding-standards.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index 00613fd3..6a667f22 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -28,7 +28,7 @@ scripts/code_style.py --fix library/file_i_edited.c tests/suites/test_suite_i_al To enforce the coding style on all files checked into Git: ```sh -scripts/code_style.py --fix library/file_i_edited.c tests/suites/test_suite_i_also_edited.function +scripts/code_style.py --fix ``` #### Exceptions to enforcement From bd5876832921a30a6e04a1b1e03440238449d3ae Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Fri, 23 Dec 2022 11:01:39 +0100 Subject: [PATCH 07/10] Cosmetic improvement Signed-off-by: Gilles Peskine --- kb/development/mbedtls-coding-standards.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index 6a667f22..ff474417 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -104,7 +104,7 @@ Do not put a space in the following places: * Before a comma: `f(x, y)` * After a unary operator: `if (!condition)`, `++x` * Before a unary operator: `x++` -* Between an array and the following opening bracket: `int a[2]; a[i]` +* Between an array and the following opening bracket: `int a[2];`, `a[i]` * Around field access symbols: `s.a`, `p->a` * After the asterisk in a pointer type: `int *p` * Between the asterisks double pointers types or derefences: `char **p`, `x + **p` From c0735960976cf01c683a63890328cfa462a06044 Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Fri, 23 Dec 2022 11:01:50 +0100 Subject: [PATCH 08/10] Document braces more thoroughly 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 --- kb/development/mbedtls-coding-standards.md | 35 ++++++++++++++++++---- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index ff474417..d6b77531 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -116,12 +116,11 @@ Do not put a space in the following places: memset(buf, 0, sizeof(buf)); ``` -### Braces placement and block declaration +### Usage and placement of braces -Braces are mandatory in control statements such as `if`, `while`, `for`, even when the content is a simple statement. -Opening braces (curly brackets) are on the same line as the control statement. +Braces (curly brackets) are **mandatory in control statements** such as `if`, `while`, `for`, even when the content is a simple statement. -Closing braces are aligned with the control statement or opening brace. They are generally alone on their line, except when followed by `else` or by the `while` of a `do ... while` statement. +Opening braces around compound statements are on the same line as the control statement if there is one. The closing brace has the same indentation as the line with the opening brace. It is generally alone on their line, except when followed by `else` or by the `while` of a `do ... while` statement. ```c do { @@ -133,6 +132,30 @@ Closing braces are aligned with the control statement or opening brace. They are } while (condition); ``` +As an exception, **the opening brace of a function definition is on its own line**, in the leftmost column. This helps editors and other tools that treat non-indented braces as delimiting toplevel blocks. + +```c +int f(void) +{ + return 42; +} +``` + +In compound type declarations, the opening brace is on the same line as the `struct`, `union` or `enum` keyword. The closing brace is on a separate line with the final semicolon. + +```c +typedef struct { + int x; + int y; +} pair_t; +``` + +Compound initializers can be on a single line if they fit. + +```c +pair_t z = { 1, 2 }; +``` + ### Formatting of lists When a function or macro call doesn't fit on a single line, put one argument per line or a sensible grouping per line. For example, in the snippet below, `input_buffer` and `input_size` are on a line of their own even though the call could fit on two lines instead of three if they were separated: @@ -149,10 +172,10 @@ Lists of items other than function arguments should generally have one item per In lists of items such array initializers and enum definitions, do include the optional comma after the last element. This simplifies merging, reordering, etc. ```c -typedef enum foo { +typedef enum { FOO_1, FOO_2, // <- do put a comma here -} +} foo_t; ``` Exceptions: you can and omit the trailing comma in structure initializers that fit on one line, or if the last element must always remain last (e.g. a null terminator). From 3b2a019197cf01e94026a2a0d10f85e7a02bc1c9 Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Fri, 23 Dec 2022 18:43:46 +0100 Subject: [PATCH 09/10] Be more specific about unary operators Signed-off-by: Gilles Peskine --- kb/development/mbedtls-coding-standards.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index d6b77531..4b4e26a2 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -102,8 +102,8 @@ Do not put a space in the following places: * 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` -* Before a unary operator: `x++` +* After a prefix unary operator: `if (!condition)`, `++x` +* Before a postfix unary operator: `x++` * Between an array and the following opening bracket: `int a[2];`, `a[i]` * Around field access symbols: `s.a`, `p->a` * After the asterisk in a pointer type: `int *p` From cc6d19585fa97a2a4d501680bea7e876911f069b Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Fri, 23 Dec 2022 18:45:37 +0100 Subject: [PATCH 10/10] Update PSA API links to the new official location Signed-off-by: Gilles Peskine --- kb/development/mbedtls-coding-standards.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kb/development/mbedtls-coding-standards.md b/kb/development/mbedtls-coding-standards.md index 4b4e26a2..a46272cd 100644 --- a/kb/development/mbedtls-coding-standards.md +++ b/kb/development/mbedtls-coding-standards.md @@ -272,7 +272,7 @@ 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. +For PSA functions, [input buffers](https://arm-software.github.io/psa-api/crypto/1.1/overview/conventions.html#input-buffer-sizes) have a `size_t xxx_size` parameter after the buffer pointer, and [output buffers](https://arm-software.github.io/psa-api/crypto/1.1/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. You can use in-out parameters for functions that receive a pointer to some buffer, and update it after parsing from or writing to that buffer: ```c