| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | 2659 - disallow dynamic arrays in recipes | Kartik K. Agaram | 2016-02-15 | 1 | -1/+20 |
| | | | | | | | | | | The rule is: every 'local' variable in a recipe must have a fixed size. Arrays can only be directly used in a recipe if their type includes a size. But we haven't been warning about this, and attempts to use array variables could cause silent memory corruption. (Hopefully this is the last hole in our type system.) | ||||
| * | 2615 | Kartik K. Agaram | 2016-01-30 | 1 | -2/+2 |
| | | |||||
| * | 2576 - distinguish allocated addresses from others | Kartik K. Agaram | 2016-01-19 | 1 | -2/+2 |
| | | | | | | | | | | | | | | | | | This is the one major refinement on the C programming model I'm planning to introduce in mu. Instead of Rust's menagerie of pointer types and static checking, I want to introduce just one new type, and use it to perform ref-counting at runtime. So far all we're doing is updating new's interface. The actual ref-counting implementation is next. One implication: I might sometimes need duplicate implementations for a recipe with allocated vs vanilla addresses of the same type. So far it seems I can get away with just always passing in allocated addresses; the situations when you want to pass an unallocated address to a recipe should be few and far between. | ||||
| * | 2571 | Kartik K. Agaram | 2016-01-19 | 1 | -0/+95 |
| Reorganize layers in preparation for a better way to manage heap allocations without ever risking use-after-free errors. | |||||