|
| 1 | +# Explicit and Implicit Inclusion of Checked Header Files |
| 2 | +Author: Sulekha Kulkarni, Approver: David Tarditi, Date Approved: |
| 3 | + |
| 4 | + |
| 5 | +# OARP |
| 6 | + |
| 7 | +| Role | Person | |
| 8 | +|-------------------|---------------| |
| 9 | +| Owner | Sulekha Kulkarni | |
| 10 | +| Approver | David Tarditi | |
| 11 | +| Reviewers | Joseph Lloyd, Mandeep Grang, Katherine Kjeer | |
| 12 | +| Reviewers | Mike Hicks and other folks at CCI | |
| 13 | + |
| 14 | + |
| 15 | +## Goal |
| 16 | +The goal of this document is to record the design considerations for allowing |
| 17 | +programs to include the checked counterparts of system header files either |
| 18 | +explicitly or implicitly during the conversion of these programs to Checked C. |
| 19 | + |
| 20 | +## Problem Summary |
| 21 | +The current approach for including checked header files, which is to explicitly |
| 22 | +replace an included header file with its checked counterpart, is inconvenient |
| 23 | +for adoption to Checked C - all the system header files included in a project |
| 24 | +need to be altered. So we need a way to implicitly include checked header |
| 25 | +files. |
| 26 | + |
| 27 | +## Conditions that a Solution must Satisfy |
| 28 | + - The solution must provide users an option to either opt into the implicit |
| 29 | + inclusion of checked header files, or opt out of it if checked header files |
| 30 | + are implicitly included by default. This flexibility is required to support |
| 31 | + custom build environments. |
| 32 | + - The solution must be easy to integrate into an existing build system. |
| 33 | + - The current approach of explicitly including checked header files must |
| 34 | + always remain a viable alternative. |
| 35 | + - The order in which the compiler driver searches the include paths must remain |
| 36 | + unaltered. |
| 37 | + - The solution must be able to accommodate any clang-specific declarations in |
| 38 | + system header files, if present (Ex.: inttypes.h). |
| 39 | + - The Checked-C-specific declarations must live in the checkedc repository. |
| 40 | + |
| 41 | + |
| 42 | +## Details of the Current Approach |
| 43 | + - The current approach supports only the explicit inclusion of checked header |
| 44 | + files. |
| 45 | + - An installed Checked C compiler places the checked counterparts of system |
| 46 | + header files like `stdio_checked.h` in the directory |
| 47 | + `$INSTALL_DIR/lib/clang/<VERSION>/include`, which clang searches before it |
| 48 | + looks in system include directories. Note that there is no alteration of the |
| 49 | + include search path to accommodate any include files related to Checked C. |
| 50 | + - If a checked header file like `stdio_checked.h` is included in a program, |
| 51 | + clang picks it up from the above location. |
| 52 | + |
| 53 | +## Solution Space |
| 54 | + - Solution 1: |
| 55 | + - Let `foo.h` be a system header file with a checked counterpart called |
| 56 | + `foo_checked.h`. We add a new file, also called `foo.h`, in the same |
| 57 | + directory that contains `foo_checked.h`. This new `foo.h` should contain |
| 58 | + `#include_next <foo.h>` plus all the Checked-C-specific declarations |
| 59 | + present in `foo_checked.h`. In addition, the original contents of |
| 60 | + `foo_checked.h` should be deleted and it should now only contain |
| 61 | + `#include <foo.h>`. |
| 62 | + - The way this solution will work: |
| 63 | + - If a program includes `foo.h`, clang will first pick up the |
| 64 | + "checked" version of `foo.h`. As this `foo.h` has a |
| 65 | + `#include_next <foo.h>`, the system `foo.h` will be picked up |
| 66 | + (infinite recursion is avoided because of include_next), and all the |
| 67 | + Checked-C-specific declarations in the "checked" version of `foo.h` |
| 68 | + will also be picked up. |
| 69 | + - If the program includes `foo_checked.h`, the line `#include <foo.h>` |
| 70 | + in `foo_checked.h` will initiate the same process as above. |
| 71 | + - **Pros**: 1) The current approach of explicit inclusion is supported. |
| 72 | + 2) No changes are required to the build system. 3) No changes are |
| 73 | + required to the order in which the include directories are searched. |
| 74 | + 4) It is convenient for automation. |
| 75 | + - **Cons**: 1) The solution does not provide a way to opt out of including |
| 76 | + checked headers. 2) While it is easy to accommodate clang-specific |
| 77 | + declarations in system header files (Checked-C-specific declarations can |
| 78 | + be added after the clang-specific declarations), this solution will |
| 79 | + require some Checked-C-specific declarations to be part of checkedc-clang |
| 80 | + repository. |
| 81 | + |
| 82 | + - Solution 2: |
| 83 | + - Have a different compiler driver to provide the facility for implicit |
| 84 | + inclusion of header files. |
| 85 | + - **Pros**: 1) The solution provides the option to opt into implicitly |
| 86 | + including checked header files. 2) The existing approach of explicit |
| 87 | + inclusion is supported. 3) In most cases integration into a build system |
| 88 | + will be easy: the `CC` variable can be redefined appropriately. 4) It is |
| 89 | + convenient for automation. |
| 90 | + - **Cons**: 1) It is a very heavy-weight solution. 2) In some cases |
| 91 | + integrating with a build system will be more involved when both the |
| 92 | + drivers are needed to compile the sources. This may happen in a scenario |
| 93 | + where most source files want implicit inclusion but a few source files |
| 94 | + want explicit inclusion because they want to directly include some system |
| 95 | + header files in order to avoid Checked-C-specific declarations. |
| 96 | + |
| 97 | + - Solution 3: |
| 98 | + - Let `foo.h` be a system header file with its checked counterpart called |
| 99 | + `foo_checked.h`. We add a new file called `foo.h` in the same directory |
| 100 | + that contains `foo_checked.h`. In this new file, we add the following: |
| 101 | + |
| 102 | + #ifdef IMPLICIT_INCLUDE_CHECKED_HDRS |
| 103 | + #include <foo_checked.h> |
| 104 | + #else |
| 105 | + #include_next <foo.h> |
| 106 | + #endif |
| 107 | + - In `foo_checked.h`, we modify `#include <foo.h>` to |
| 108 | + `#include_next <foo.h>`. |
| 109 | + |
| 110 | + - The way this solution will work: |
| 111 | + - If a program includes `foo.h`, clang will pick up either |
| 112 | + `foo_checked.h` or the system `foo.h` depending on whether or not |
| 113 | + `-DIMPLICIT_INCLUDE_CHECKED_HDRS` is specified on the compilation |
| 114 | + commandline. Therefore specifying this flag will cause the implicit |
| 115 | + inclusion of the checked counterpart of `foo.h`, which will make it |
| 116 | + convenient for automation. Not specifying the commandline flag will |
| 117 | + not perform implicit inclusion, providing a mechanism to opt out of |
| 118 | + implicit inclusion. Infinite recursion is avoided because of |
| 119 | + `#include_next`. |
| 120 | + - If a program includes `foo_checked.h` current behavior will prevail. |
| 121 | + The above flag has no effect on the explicit inclusion of checked |
| 122 | + header files. |
| 123 | + |
| 124 | + - **Pros**: 1) The solution provides a way to opt into implicit inclusion |
| 125 | + of checked header files. 2) The existing approach of explicit inclusion |
| 126 | + is supported. 3) In most cases integration with the build system is easy: |
| 127 | + the flag `-DIMPLICIT_INCLUDE_CHECKED_HDRS` is passed to the compilation |
| 128 | + of all source files through the `CFLAGS` variable. 4) No changes are |
| 129 | + required to the order in which include directories are searched. 5) It |
| 130 | + is convenient for automation. |
| 131 | + |
| 132 | + - **Cons**: 1) In some cases integration with the build system will be more |
| 133 | + involved if the above flag needs to be passed to the compilation of most |
| 134 | + source files and avoided for a few source files that may want to directly |
| 135 | + include system header files in order to avoid Checked-C-specific |
| 136 | + declarations. 2) It is difficult to accomodate clang-specific |
| 137 | + declarations. |
| 138 | + |
| 139 | +## Proposed Solution: |
| 140 | + |
| 141 | +The proposed solution is as follows: |
| 142 | + - We will implicitly include checked header files by default and provide the |
| 143 | + compilation flag NO_IMPLICIT_INCLUDE_CHECKED_HDRS to opt out of the implicit |
| 144 | + inclusion. |
| 145 | + - For header files that do not have clang-specific declarations, but have |
| 146 | + Checked-C-specific declarations (there are 13 such header files at present), |
| 147 | + we will do the following: |
| 148 | + - For each system header file, say `foo.h`, that does not have |
| 149 | + clang-specific declarations but has Checked-C-specific declarations, we |
| 150 | + will add a new file also called `foo.h` that will contain the following: |
| 151 | + |
| 152 | + #if !defined __checkedc || defined NO_IMPLICIT_INCLUDE_CHECKED_HDRS |
| 153 | + #include_next <foo.h> |
| 154 | + #else |
| 155 | + #include <foo_checked.h> |
| 156 | + #endif |
| 157 | + |
| 158 | + - The file `foo_checked.h` will contain `#include_next <foo.h>` and the |
| 159 | + Checked-C-specific declarations. |
| 160 | + |
| 161 | + - For a system header file that contains clang-specific declarations and also |
| 162 | + Checked-C-specific declarations (there is one such header file at present), |
| 163 | + we will do the following: |
| 164 | + - Let `bar.h` be such a header file. Then there already |
| 165 | + exists a file called `bar.h` in the `clang/lib/Headers` directory, |
| 166 | + which contains clang-specific declarations in the following format: |
| 167 | + |
| 168 | + #include_next <bar.h> |
| 169 | + <currently existing clang-specific declarations> |
| 170 | + |
| 171 | + At the end of this pre-existing `bar.h`, we will add the following: |
| 172 | + |
| 173 | + #if defined __checkedc && !defined NO_IMPLICIT_INCLUDE_CHECKED_HDRS |
| 174 | + #include <bar_checked_internal.h> |
| 175 | + #endif |
| 176 | + |
| 177 | + - All the Checked-C-specific declarations (that are currently present in |
| 178 | + `bar_checked.h`) will be moved to `bar_checked_internal.h`. The file |
| 179 | + `bar_checked.h` will be modified to contain just the following: |
| 180 | + |
| 181 | + #include <bar.h> |
| 182 | + #include <bar_checked_internal.h> |
0 commit comments