Исходное сообщение
"Проект GCC разрешил приём изменений без передачи Фонду СПО п..." Отправлено n00by, 04-Июн-21 10:11
> Но это же не значит, что шланг компилирует "лучше", чем gcc. Ну да, потому у меня там "лучше, чем нужно". > Просто > в этом случае случилось так, что способ шланга совпал с тем, > что задумал программист. Предполагаю, что в Clang специально так и задумано, что бы "помочь программистам". > В другом случае, он мог не совпасть. В > другом случае программист мог задумать такое: > rtrie_index next = &rt->n[idx].next > *next = rtrie_new_node(rt, chr); > но написать то же самое: > rt->n[idx].next = rtrie_new_node(rt, chr); > И в этом случае шланг бы оказался не прав. Здесь возникает интересный вопрос: имеется ли у разработчиков Clang статистика по подобным ошибкам? У меня таких данных нет, но второй вариант выглядит излишне сложным, полагаю, он встречается реже. > Тут мне кажется дело в том, что вы разрабатываете на шланге, и > поэтому когда шланг не угадывает задумку программиста, программист это быстро узнаёт, > и баг не выходит за пределы его рабочего компьютера. Разрабатывали бы > на gcc, было бы ровно то же самое, но просто другие > случаи UB уходили бы в продакшн. Пока не вижу пример, который подтверждал бы вторую часть гипотезы. С первой согласен. Наблюдал однажды, как "разработчики" одной автономной ОС собирали firefox при помощи GCC, и он падал у пользователей. Локализовать ошибку они не смогли и принялись собирать Clang-ом, "что бы быть ближе к апстриму". Вот тогда я предположил, что в исходниках firefox написано что-то подобное (к тому же на С++, где n инкапсулирован).

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Но это же не значит, что шланг компилирует "лучше", чем gcc. > Ну да, потому у меня там "лучше, чем нужно". >> Просто >> в этом случае случилось так, что способ шланга совпал с тем, >> что задумал программист. > Предполагаю, что в Clang специально так и задумано, что бы "помочь программистам". >> В другом случае, он мог не совпасть. В >> другом случае программист мог задумать такое: >> rtrie_index next = &rt->n[idx].next >> *next = rtrie_new_node(rt, chr); >> но написать то же самое: >> rt->n[idx].next = rtrie_new_node(rt, chr); >> И в этом случае шланг бы оказался не прав. > Здесь возникает интересный вопрос: имеется ли у разработчиков Clang статистика по подобным > ошибкам? У меня таких данных нет, но второй вариант выглядит излишне > сложным, полагаю, он встречается реже. >> Тут мне кажется дело в том, что вы разрабатываете на шланге, и >> поэтому когда шланг не угадывает задумку программиста, программист это быстро узнаёт, >> и баг не выходит за пределы его рабочего компьютера. Разрабатывали бы >> на gcc, было бы ровно то же самое, но просто другие >> случаи UB уходили бы в продакшн. > Пока не вижу пример, который подтверждал бы вторую часть гипотезы. С первой > согласен. Наблюдал однажды, как "разработчики" одной автономной ОС собирали firefox при > помощи GCC, и он падал у пользователей. Локализовать ошибку они не > смогли и принялись собирать Clang-ом, "что бы быть ближе к апстриму". > Вот тогда я предположил, что в исходниках firefox написано что-то подобное > (к тому же на С++, где n инкапсулирован).
	Введите код, изображенный на картинке: