Panic! At the 0xC0D3

Pointers Are Complicated
ого пост не про раст

Правда ли, что при компиляции корректно (и полезно) считать указатели на память просто "числами"?
Утверждается, что нет, а самое забавное - дополнительная информация может быть динамической в контексте компиляции (ци шо)
https://www.ralfj.de/blog/2020/12/14/provenance.html

Я не буду пересказывать статью, лучше сходите сами почитайте, но попробую добавить пару вещей:

Когда мы говорим о метадате для компиляции, мы обычно говорим о чем-то статическом, что зафиксированно в коде: типы переменных, какие-нибудь подсказки для компилятора аля __builtin_expect и т.п. Но pointer provenance это динамическая метадата, в том смысле, что ее нужно считать во время компиляции, она зависит не только от типа, но и от конкретной переменной, для который мы ее считаем.

В статье приводится довольно сложный пример того, когда считать указатели "просто числами" является некорректным, но как будто идея раскрывается не совсем полностью. Pointer provenance это по сути идея добавлять для каждой переменной (не для типа!) с типом указателя метаданные аля "какой кусок памяти является валидным для этого указателя" и/или "откуда этот указатель появился".

Тогда, компилятор может не только запрещать невалидные оптимизации, но и разрешать делать дополнительные (опять же, эти оптимизации в контексте функции могут быть валидными, но индивидуально могут быть неправильными, если дополнительных ограничений на указатель нет)
1. Например, если мы знаем, что у нас есть указатель на 10 элементов, то мы не можем смотреть дальше него (т.к. это UB) (пример придумывать лень)
2. Помимо этого, если мы знаем, что два указателя появляются из двух разных мест (аля два разных вызова malloc), то мы знаем, что они не могут пересекаться по памяти (классический пример это оптимизации раста, которые он делает, т.к. у него этот инвариант всегда "включен")
3. Комбинации предыдущих: делаем указатель на кусок памяти, получаем другой указатель из первого - все еще знаем, что он не может указывать за пределы первого

Вот так считаешь всю жизнь компьютеры детерменированными машинами все данные как битики и байтики, а потом на тебе...

www.ralfj.de

Pointers Are Complicated II, or: We need better language specs

Some time ago, I wrote a blog post about how there’s more to a pointer than meets the eye. One key point I was trying to make is that just because two pointers point to the same address...

👍4🔥3

www.tgoop.com/paniccode/34

691 viewsLev, Feb 22, 2024 at 23:25

Pointers Are Complicated
ого пост не про раст

Правда ли, что при компиляции корректно (и полезно) считать указатели на память просто "числами"?
Утверждается, что нет, а самое забавное - дополнительная информация может быть динамической в контексте компиляции (ци шо)
https://www.ralfj.de/blog/2020/12/14/provenance.html

Я не буду пересказывать статью, лучше сходите сами почитайте, но попробую добавить пару вещей:

Когда мы говорим о метадате для компиляции, мы обычно говорим о чем-то статическом, что зафиксированно в коде: типы переменных, какие-нибудь подсказки для компилятора аля __builtin_expect и т.п. Но pointer provenance это динамическая метадата, в том смысле, что ее нужно считать во время компиляции, она зависит не только от типа, но и от конкретной переменной, для который мы ее считаем.

В статье приводится довольно сложный пример того, когда считать указатели "просто числами" является некорректным, но как будто идея раскрывается не совсем полностью. Pointer provenance это по сути идея добавлять для каждой переменной (не для типа!) с типом указателя метаданные аля "какой кусок памяти является валидным для этого указателя" и/или "откуда этот указатель появился".

Тогда, компилятор может не только запрещать невалидные оптимизации, но и разрешать делать дополнительные (опять же, эти оптимизации в контексте функции могут быть валидными, но индивидуально могут быть неправильными, если дополнительных ограничений на указатель нет)
1. Например, если мы знаем, что у нас есть указатель на 10 элементов, то мы не можем смотреть дальше него (т.к. это UB) (пример придумывать лень)
2. Помимо этого, если мы знаем, что два указателя появляются из двух разных мест (аля два разных вызова malloc), то мы знаем, что они не могут пересекаться по памяти (классический пример это оптимизации раста, которые он делает, т.к. у него этот инвариант всегда "включен")
3. Комбинации предыдущих: делаем указатель на кусок памяти, получаем другой указатель из первого - все еще знаем, что он не может указывать за пределы первого

Вот так считаешь всю жизнь компьютеры детерменированными машинами все данные как битики и байтики, а потом на тебе...

BY Panic! At the 0xC0D3