LLVM 10.0

Арифметика указателей в C и C++ разрешается только в пределах массивов, в соответствии со стандартами

Что имеется ввиду?

Арифметика указателей в C и C++ разрешается только в пределах массивов

Так:

int main()
{
	int a[2][2] = {};
	int i = 2;
	a[0][i] = 0;
}

ловит, но вот так:

int main()
{
	int a[2][2] = {};
	int i = 2;
	int* pi = &a[0][0];
	pi[i] = 0;
}

уже нет. :/

А должен? Сначала ты делаешь указатель типа int, а потом пытаешься работать с ним, как с массивом. Да ещё и 0 пытаешься задать в качестве адреса.

А должен?

Нет, но хотелось бы, чтоб ловил и так тоже.

Да ещё и 0 пытаешься задать в качестве адреса.

Што??!

C/C++ - стабильность, надёжность, качество. Выберите 0.

Нет, но хотелось бы, чтоб ловил и так тоже.

Каким образом, если a — массив, с известными в compile-time размерами, а pi — обычный указатель?

Каким образом

Без поддержки со стороны железа, думаю, никаким.

C/C++ - стабильность, надёжность, качество. Выберите 0.

забавно слышать такое от расто-фанатика, который использует плюсовый llvm… хотя нет, скорее закономерно.

int* pi = &a[0][0]; pi[i] = 0;

В первой строчке создаётся указатель на элемент массива a[0][0]. Во второй строчке идёт запись в указатель не разыменовывая его, то есть записывается новый адрес(указатель - это адрес).

Я не прав?

Я не прав?

Не прав.

Что же тогда на самом делают эти две строчки и в чём я ошибась?

The expression E1[E2] is identical (by definition) to *((E1)+(E2)) … except that…

Спасибо.

в указатель не разыменовывая его

pi[i] ≡ *(pi+i)

и что он по твоему «ловить» должен? [code=c] int main() { int a[2][2] = {{1,2},{3,4}}; int i = 2; int *p = &a[0][0]; printf(«%d\n», p[i]); }

$ ./a.out 3

[/code]

https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html#undefined-behavior-sanitizer-ubsan

Нельзя просто взять (c) и прибавить к указателю число. Только в некоторых случаях можно.

Это, кстати, может много чего поломать, ибо сишники любят извращения с указателями. Хотя похоже что clang пока что ведет себя осторожно и ломает только некоторые такие случаи.

и что он по твоему «ловить» должен?

UB.

Что твой код должен мне сказать, я не понял.

А вот за это действительно спасибо! Каждень день узнаю что-то новое.

out of range - это совсем про другое.

Арифметика указателей в C и C++ разрешается только в пределах массивов, в соответствии со стандартами

Этот пункт плохо написан, может вводить в заблуждение.

Арифметика-то действительно всегда была запрещена вне массивов, но конкретно в этом релизе фактически запрещены только частные случаи: нельзя прибавлять к нулевому указателю, нельзя вычитать из указателя так чтобы получить нулевой. Если кто-то таким занимается - программа будет сломана.

Этот пункт плохо написан, может вводить в заблуждение.

Действительно. Я-то подумал ловят выход за границы массивов. А добавили проверку на какую-то фигню, реально не встречающуюся.

Я-то подумал ловят выход за границы массивов

Так его давно уже ловят. Если что-то не поймали - ну, не смогли.

А добавили проверку на какую-то фигню, реально не встречающуюся

Там дело скорее в другом: оптимизатор теперь полагается, что эта фигня не встречается. Наверняка где-то все равно встретится, сишники любят извращения.

flang в этот выпуск так и не успели добавить.

Он только пришёл, а ты уже бабахнул. Да, ты прав, это закономерно.

В те времена выбор был либо Си, либо кресты. Из двух кучек говна выбрали ту, которая поменьше. Они не знали, что эта кучка будет расти в геометрической прогрессии.

int a[2][2] = {};

так нельзя делать

int a[2][2] = {0}; только так можно

Вот именно, что известными в compile-time размерами и индексом. Достаточно тривиально отследить то, как был получен указатель p и то, куда по нему пытаются писать, если все необходимое было известно в compile-time.

Почему UB?

Многомерные массивы идут же подряд.

int a[2][2];

равносилен

int a[4];

по структуре памяти.

Правильно тебе аноним написал…

Тебе сколько мозилла платит?

страус труп перелогинься

Безопасность Rust основывается не на LLVM, а на статическом анализе кода. Если код удовлетворяет требованиям статического анализатора, а программистом соблюдены контракты при написании unsafe-кода (при наличии такового), и код при этом корректно скомпилирован LLVM, то код действительно будет безопасным. Проблемы LLVM проблемами Rust не являются, хотя и затрагивают его; нарушение контрактов – твой личный добровольный выстрел в ногу, ССЗБ.

а тут вы оба правы.

Если нужен занулённый массив, то:

В С нужно с 0 делать.

В С++ можно и просто скобочки и с нулём…

а тут вы оба правы.

что?

int a[2][2]; ТАК МОЖНО

int a[2][2] = {0}; ТАК МОЖНО

int a[2][2] = {}; ТАК НЕЛЬЗЯ у него в оригинале ТАК, и так НЕЛЬЗЯ

глаза разуйте

В С++ можно и просто скобочки и с нулём…

нет

Можно, я просто хорошо помню cppreference, и сказал не просто так:

https://imgur.com/a/42h8OhT

https://en.cppreference.com/w/c/language/array_initialization

Можно, я просто хорошо помню cppreference, и сказал не просто так:

нельзя

MSVS знает лучше тебя

это говно не соответствует стандартам

нельзя

MSVS знает лучше тебя

Ты бредишь? Специально открыл VS 2019 и проверил:

https://imgur.com/a/TytsEkP

Ты бредишь? Специально открыл VS 2019 и проверил:

скриншота не будет, лень винду ребутать, у меня MSVS во всех проектах на {} ругается и не дает собрать, даже с офф реп, и не только у меня

Ты забыл сказать версию msvs. На 2017 тоже работает.

Шёл 2020 год. Сишники спорят как индексировать массив. Это даже похлеще Шок от С. Как склеивать строки?

Прочел комменты и понял, что Си и быдлосикодеров надо закопать...

In Rust we trust!

А стандарт разрешает, между прочим.

Сишники спорят как индексировать массив

Шел 2020. RazrFalcon по-прежнему не понимал, о чем говорят другие.

у меня MSVS во всех проектах на {} ругается и не дает собрать, даже с офф реп, и не только у меня

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

Поведение в ряде случаев приближено к поведению GCC.

Это победа или предательство?

Напомни пожалуйста, а что по стандарту в случае

uint8_t *baseaddr = (uint8_t*)(DEVICE_BASE_ADDR);
baseaddr[1] = 0;

?

где DEVICE_BASE_ADDR - адрес начала блока в физическом адресном пространстве, где расположены регистры управления управления какой-либо периферией

Шок от С. Как склеивать строки?

Ах Эдик, Эдик... АААА!!!

Это си. Они откуда-то взяли, что арифметика указателей - это ub в с++ и носятся с этим, хотя с++ совместим с си и const char* какбы есть везде и работает без ub. Скорее всего им кто-то наврал, но шланг в последнее время становится все менее адекватным. Например на «abc» + 1 выдает совершенно неадекватное предупреждение. Причем я это встретил в исходниках lua, который не то чтобы васяны пишут, васяны скорее пишут шланг.