3 ms·

Heh, this is a dissertation, and quite a bit to discuss. Maybe tomorrow there could be good discussion here. A few little nuggets of discussion: Section 2.1 s

by uxp100 6y ago

Heh, this is a dissertation, and quite a bit to discuss. Maybe tomorrow there could be good discussion here. A few little nuggets of discussion: Section 2.1 seems like it could stand alone if you're looking for vocabulary and definitions about memory safety. Section 2.2 discusses type safety, and mentions C's weakness here. This is what most interests me about Rust, since the c software I spent several years working on did not contain any allocations, (I've had some short but confused conversations with rust evangelists, No, we don't malloc, we don't free, and unsafe exists on a different axis than if values put into DMA engines are sanitized). I don't think the run time solutions mentioned are the way to go, it really needs to be baked into the language, but some of these tools sound fun to play with. Section 5.4 talks about Unions. I was mistaken about the size of unions, which I thought always (or practically always) would be the size of the largest member, but the example given shows LLVM does not always behave that way, due to alignment requirements If I understand correctly.

audidude 6y ago
> Section 5.4 talks about Unions. I was mistaken about the size of unions, which I thought always (or practically always) would be the size of the largest member, The array'ability of the union is going to determine the size. So if you have a pointer at a given offset in one of the union'd structures it may need to increase the size of the union so that when used in an array the pointer will always stay aligned. (Same goes for any other type with alignment requirements).
unanswered 6y ago
Unless I'm missing something by skipping straight to 5.4, the explanation of unions is hot garbage. None of the examples are sane as they are all larger than the smallest array of a naturally-aligned type with the same alignment as the most-aligned field, such that this array is not smaller than the largest field in the union — which would be a structure with the same alignment and stride as the original union. (You could also "cover" it with a more precise struct which may be smaller than its own stride, which is what I think the paper was trying to explain, but the examples are still nonsense.)

by uxp100 6y ago

audidude 6y ago

> Section 5.4 talks about Unions. I was mistaken about the size of unions, which I thought always (or practically always) would be the size of the largest member, The array'ability of the union is going to determine the size. So if you have a pointer at a given offset in one of the union'd structures it may need to increase the size of the union so that when used in an array the pointer will always stay aligned. (Same goes for any other type with alignment requirements).

unanswered 6y ago

Unless I'm missing something by skipping straight to 5.4, the explanation of unions is hot garbage. None of the examples are sane as they are all larger than the smallest array of a naturally-aligned type with the same alignment as the most-aligned field, such that this array is not smaller than the largest field in the union — which would be a structure with the same alignment and stride as the original union. (You could also "cover" it with a more precise struct which may be smaller than its own stride, which is what I think the paper was trying to explain, but the examples are still nonsense.)