Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | 2576 - distinguish allocated addresses from others | Kartik K. Agaram | 2016-01-19 | 1 | -43/+88 |
| | | | | | | | | | | | | | | | | 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. | ||||
* | 2574 | Kartik K. Agaram | 2016-01-19 | 1 | -11/+4 |
| | |||||
* | 2573 - check product type of 'new' | Kartik K. Agaram | 2016-01-19 | 1 | -4/+29 |
| | | | | | | | | | | | I realize that my current doesn't allow nesting a:b:c linear type syntax inside a dilated property. So you can't currently say: (recipe address:number) Need to fix that at some point. Non-trivial since linear syntax is oblivious to dilated syntax. I should probably make the dilated syntax more fundamental and introduce it at an earlier layer. | ||||
* | 2571 | Kartik K. Agaram | 2016-01-19 | 1 | -0/+418 |
Reorganize layers in preparation for a better way to manage heap allocations without ever risking use-after-free errors. |