> Но это же не значит, что шланг компилирует "лучше", чем 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 инкапсулирован).