Как стать автором
Обновить

Комментарии 13

Необходимо регулярно проводить проверку GCC как LLVM. Чем раньше будут обнаружены проблемы в коде компилятора, тем лучше. От стабильности компиляторов зависит работа разработчиков, которые их используют.

Возьмётесь? :)

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

КМК под это определение

готовые решения общего назначения [для написания парсеров]

Подходит какой-нибудь antlr, но уж никак не LLVM

Ошибка 1 - типичное последствие дурного дизайна языка. Запятая по сути отбрасывает выражение до неё и возвращает то, что стоит после неё. При этом я не вижу случая, где это было бы реально полезно. Посему было бы неплохо, чтобы компиляторы предупреждение на её использование выдавали (если ещё этого не делают).

Ошибка 7 - не понятно, почему этот код компилируется. Сравнивать указатели на == и != с нулём ещё имеет смысл. Но зачем нужно сравнение на больше/меньше? Тут надо бы ошибку компиляции выдавать.

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

Сравнение указателя с указателем это одно. Это действительно полезно. Но в статье показан случай сравнения указателя с численной константой, что смысла никакого не имеет.

Меня недавно удивило, что такой код не компилируется (хотя я считал, что должен):

void foo(int *out) {
    out = 0x01;
}

Да, я хочу записать единицу как адрес. Возможно, msvc компилятор поумнел.

С чего бы он должен-то? Используйте преобразование типов, они для подобных случаев и сделаны.

Это компилируется в C (хотя и с варнингом, GCC: incompatible integer to pointer conversion assigning to 'int *' from 'int' [-Wint-conversion]).

И не компилируется в C++. И это замечательно.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий