1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
Each item in Wikipedia's [list of types of memory errors](https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_errors) and what Crowbar does to prevent them.
# Access errors
## Buffer overflow
Crowbar addresses buffer overflow with bounds checking.
In C, the type `char *` can point to a single character, a null-terminated string of unknown length, a buffer of fixed size, or nothing at all.
In Crowbar, the type `char *` can only point to either a single character or nothing at all.
If a buffer is declared as `char[50] name;` then it has type `char[50]`, and can be implicitly converted to `(char[50])*`, a pointer-to-50-chars.
If memory is dynamically allocated, it works as follows:
```crowbar
void process(size_t bufferSize, char[bufferSize] buffer) {
// do some work with buffer, given that we know its size
}
int main(int argc, (char[1024?])[argc] argv) {
size_t bufferSize = getBufferSize();
(char[bufferSize])* buffer = malloc(bufferSize);
process(bufferSize, buffer);
free(buffer);
}
```
Note that `malloc` as part of the Crowbar standard library has signature `(void[size])* malloc(size_t size);` and so no cast is needed above.
In C, `buffer` in `main` would have type pointer-to-VLA-of-char, but `buffer` in `process` would have type VLA-of-char, and this conversion would emit a compiler warning.
However, in Crowbar, a `(T[N])*` is always implicitly convertible to `T[N]`, so no warning exists.
(This is translated into C by dereferencing `buffer` in `main`.)
Note as well that the type of `argv` is complicated.
This is because the elements of `argv` have unconstrained size.
TODO figure out if that's the right way to handle that
## Buffer over-read
bounds checking again
## Race condition
uhhhhh 🤷♀️
## Page fault
bounds checking, dubious-pointer checking
## Use after free
`free(x);` not followed by `x = NULL;` is a compiler error.
`owned` and `borrowed` keywords
# Uninitialized variables
forbid them in syntax
## Null pointer dereference
dubious-pointer checking
## Wild pointers
dubious-pointer checking
# Memory leak
## Stack exhaustion
uhhhhhh 🤷♀️
## Heap exhaustion
that counts as error handling, just the `malloc`-shaped kind
## Double free
this is just use-after-free but the use is calling free on it
## Invalid free
don't do that
## Mismatched free
how does that even happen
## Unwanted aliasing
uhhh don't do that?
|
