diff options
| author | Runxi Yu <me@runxiyu.org> | 2024-12-01 20:16:59 +0800 |
|---|---|---|
| committer | Runxi Yu <me@runxiyu.org> | 2024-12-01 20:16:59 +0800 |
| commit | 44da3efe6828a43fcb768bd8af4a4778be5ef062 (patch) | |
| tree | ac0262499e434e3a20713fa46c0283c83f3e8748 | |
| parent | Add some seperate comments on nofail, and a place to put other such comments (diff) | |
| download | e2-spec-44da3efe6828a43fcb768bd8af4a4778be5ef062.tar.gz e2-spec-44da3efe6828a43fcb768bd8af4a4778be5ef062.tar.zst e2-spec-44da3efe6828a43fcb768bd8af4a4778be5ef062.zip | |
reasoning: Explicitly mention unlocking as a candidate for nofail
| -rw-r--r-- | reasoning | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -3,7 +3,7 @@ Some reasons for some stuff done here. Not going to be a part of the specificati nofail: If you can get into a situation where there's no way to free resources you no longer need, you have done something wrong. If the language doesn't give you a way to do the above, the language has done something wrong. - free(), close(), and other such should be marked as `nofail`, so that you don't run out of stack space trying to call them, resulting in inability to free resources. + free(), close(), unlocking, and other such should be marked as `nofail`, so that you don't run out of stack space trying to call them, resulting in inability to free resources. Good for situations where failing to call a function partway through is deemed (by the programmer) undesirable. |