Joakim Bech | 8e5c5b3 | 2018-10-25 08:18:32 +0200 | [diff] [blame] | 1 | .. _coding_standards: |
| 2 | |
| 3 | Coding standards |
| 4 | ################ |
| 5 | |
| 6 | In this project we are trying to adhere to the same coding convention as used |
| 7 | in the Linux kernel (see CodingStyle_). We achieve this by running |
| 8 | checkpatch_ from Linux kernel. However there are a few exceptions that we had |
| 9 | to make since the code also follows GlobalPlatform standards. The exceptions |
| 10 | are as follows: |
| 11 | |
| 12 | 1. **CamelCase** for GlobalPlatform types is allowed. |
| 13 | |
| 14 | 2. We **do not** run checkpatch on third party code that we might use in |
| 15 | this project, such as LibTomCrypt, MPA, newlib etc. The reason for that |
| 16 | and not doing checkpatch fixes for third party code is because we would |
| 17 | probably deviate too much from upstream and therefore it would be hard to |
| 18 | rebase against those projects later on and we don't expect that it is |
| 19 | easy to convince other software projects to change coding style. |
| 20 | |
| 21 | 3. **All** variables **shall be** initialized to a well known value in one |
| 22 | or another way. The reason for that is that we have had potential |
| 23 | security issues in the past that originated from not having variables |
| 24 | initialized with a well defined value. We have also investigate various |
| 25 | toolchain flags that are supposed to help out finding uninitialized |
| 26 | variables. Unfortunately our conclusion is that you cannot trust the |
| 27 | compilers here, since there are corner cases where compilers cannot |
| 28 | reliably give a warning. |
| 29 | |
Jens Wiklander | 6615107 | 2019-04-11 11:14:42 +0200 | [diff] [blame] | 30 | Variables are initialized according to these general guidelines: |
| 31 | |
| 32 | * Scalars (and types like ``time_t`` which are standardized as scalars) |
| 33 | are initialized with ``0``, unless another value makes more sense. |
| 34 | |
| 35 | * For optee_client we need maximum portability. So only initialize |
| 36 | struct types (and ``pthread_t``) with ``memset()`` unless there is a |
| 37 | good reason not to do so. |
| 38 | |
| 39 | * For the rest of the gits we assume that a recent version of GCC or |
| 40 | Clang is used so we initialize structs with ``{ }`` in order to avoid |
| 41 | the more clumsy ``memset()`` procedure. Types like ``pthread_t`` |
| 42 | which can be a scalar or a composite type are initialized with |
| 43 | ``memset()`` in order to minimize the amount of future headache. |
| 44 | |
Joakim Bech | 8e5c5b3 | 2018-10-25 08:18:32 +0200 | [diff] [blame] | 45 | Regarding the checkpatch tool, it is not included directly into this project. |
| 46 | Please use checkpatch.pl from the Linux kernel git in combination with the local |
| 47 | `checkpatch script`_. |
| 48 | |
Markus S. Wamser | 32c71cd | 2020-02-17 16:49:39 +0100 | [diff] [blame] | 49 | There are also targets for common use cases in the Makefiles: |
| 50 | |
| 51 | .. code-block:: none |
| 52 | |
| 53 | make checkpatch #check staging and working area |
| 54 | make checkpatch-staging #check staging area (added, but not committed files) |
| 55 | make checkpatch-working #check working area (modified, but not added files) |
| 56 | |
Joakim Bech | 8e5c5b3 | 2018-10-25 08:18:32 +0200 | [diff] [blame] | 57 | .. _checkpatch script: https://github.com/OP-TEE/optee_os/blob/master/scripts/checkpatch.sh |
| 58 | .. _checkpatch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl |
| 59 | .. _CodingStyle: https://www.kernel.org/doc/html/latest/process/coding-style.html |
| 60 | .. _repository-structure: fixme::after-sphinks-updates |