В чём смысл этого?

Чтобы ты был уверен, что все твои аргументы - аргументы, а не междометия.

чо?

В данном случае, шланг выдаёт предупреждение на валидные аргументы, которые ни на что не влияют. К всякой ереси это отношения не имеет.

Ну, ты написал что-то, на что компилятору полностью наплевать, и при этом ты уверен, что как-то рулишь процессом, но по факту нет. Об этом и сообщает.

Но это не проблема исходного кода, это проблема флагов компилятора. При этом это подаётся как ошибка в случае с -Werror.

В общем-то, натолкнулся я на это, когда решил вместо gcc вставить шланг в один проект ради тестов. И для gcc там нужна была пачка аргументов, которые шлангу в данном случае не понравились.

В любом случае, я пока не представляю ошибки, которую этим можно предотвратить.

Хи-хи. Компилятор - это такой суровый мужик, а ты в роли девочки, которая что-то там щебечет совершенно неважное.

Отловить опечатки в makefile?

Не-а. Компилятор – это такая животная (своенравная, да), которую надо укротить и объездить. А программист (если он действительно программист) – укротитель.

В итоге процесса все эти clang, gcc и icc должны сидеть на табуретах и прыгать по команде дрессировщика на глазах у изумлённой публики. «А иначе зачем…»

Так сделай -Wno-unused-command-line-argument или -Wno-error=unused-command-line-argument

А что на такие аргументы скажет gcc ?

-Wno-unused-command-line-argument gcc игнорит, на -Wno-error выдаёт ошибку.

Вопрос: нахрена это? Чтобы что? Как это делает хоть чью-то жизнь лучше?

У меня есть версия: чтобы писать configure-time тесты на поддержку тех или иных аргументов компилятором.

Да без особой разницы, можно в мейкфайле ловить текущий CC компилятор и задавать разные флаги.

Всё правильно делает. Мусор в аргументах это или опечатка или ошибка. Чем раньше заметишь, тем лучше.

Глупости.

Да без особой разницы, можно в мейкфайле ловить текущий CC компилятор и задавать разные флаги.

Это, конечно, очень классно. Особенно когда тебе совершенно делать нечего помимо этого.

Не-а. Компилятор – это такая животная (своенравная, да), которую надо укротить и объездить. А программист (если он действительно программист) – укротитель.

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

В чём смысл этого?

А есть примеры ненужных ворнингов? Потому что по ссылке-то все ворнинги выглядят как полезные.

Но это не проблема исходного кода, это проблема флагов компилятора.

Это проблема вызова с недефолтными ключами компилятора и следовательно исходного кода в совокупности с кодом системы сборки проекта. Хотите завершаться по ошибке при предупреждении — ну так вычищайте все предупреждения, благо ручки есть: (void)&unused;

благо ручки есть: (void)&unused;

Ээээ… а это тут причём? лол

когда решил вместо gcc вставить шланг

Плохая идея. Лучше напиши в ридми что шланг не поддерживается, а в build-deps пакета вставь gcc.

Конкретно варнинг, который сломал мне сборку:

clang: error: argument unused during compilation: ‘-pie’ [-Werror,-Wunused-command-line-argument]

Выдается если отдельно собирать объектники без линковки. Т.е. что-то типа clang -o file.o -c -pie -fpie null.c.

Ээээ… а это тут причём? лол

В смысле? Это и есть правильный способ закрыть это предупреждение и самому себе и другим в коде указать, что это именно unused.

В смысле? Это и есть правильный способ закрыть это предупреждение и самому себе и другим в коде указать, что это именно unused.

Ты мне про неиспользуемые параметры функций, похоже, пишешь. Тред не об этом вообще. Прочитай ещё раз и посмотри коммент чуть выше.

Ты мне про неиспользуемые параметры функций, похоже, пишешь.

А, и правда, надо больше спать :) Извини.

Плохая идея. Лучше напиши в ридми что шланг не поддерживается, а в build-deps пакета вставь gcc.

Угадал автора даже до конца не дочитав коммент лол :DDDDD

Согласен, очень классно!

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

А точно нужный? Можно примерный сценарий, в котором это спасает от ошибок?

Смысл в приучении убирать за собой.

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

Можно примерный сценарий, в котором это спасает от ошибок?

Ты конпелял несколько исходников в один бинарник однострочником. Потом решил разбить на разные шаги, но неправильно разделил опции компиляции и компоновки.

Сишники безнадёжны, там язык не для слабых телом и духом

Можно примерный сценарий, в котором это спасает от ошибок?

Ты конпелял несколько исходников в один бинарник однострочником. Потом решил разбить на разные шаги, но неправильно разделил опции компиляции и компоновки.

Окей, к какой именно ошибке приведёт передача -L при компиляции или передача -I при компоновке? Какой неправильный результат я получу?

Какой неправильный результат я получу?

Ты не получишь никакого результата, что является ошибкой. Если продолжать твою логику дальше, то можно указывать в аргументах несуществующие файлы. Не, ну а чо? Ты ведь не получишь никакого «неправильно результата» если укажешь файл, которого нет на диске, не так ли?

Ты не получишь никакого результата, что является ошибкой.

Чо? При вызове gcc -L/some/path -c -o file.o file.c я получаю вполне конкретный результат. Путь к библиотекам, ясен хер, игнорируется.

Если продолжать твою логику дальше, то можно указывать в аргументах несуществующие файлы.

Это не моя логика. Крайне тупой аргумент, не делай так.

Если у этих аргументов нету документированных значений по умолчанию - то правильно тебе эцих с гвоздями делают

This:

...-Wno-error=unused-command-line-argument

Как оказалось, этот вариант хуже тем, что его не принимает gcc, то есть перед использованием нужен иф по компилятору или тест на прверку поддержки флага.

Есть. Смотри сюда: В чём смысл этого? (комментарий)

При вызове gcc

gcc-проблемы.

Это не моя логика.

Твоя, твоя. Путь к файлу такой же аргумент командной строки, как и любой другой аргумент. Если тебе не важна валидность аргумента в одном случае, то нет никаких причин желать её в другой.

gcc-проблемы.

Ну или шланг делали известные тут программисты-анальники. Я склоняюсь к этому сценарию.

Твоя, твоя. Путь к файлу такой же аргумент командной строки, как и любой другой аргумент. Если тебе не важна валидность аргумента в одном случае, то нет никаких причин желать её в другой.

Так аргумент-то валиден. Просто он тут не используется. Т.е. компилятор получил больше информации, чем ему нужно для сборки конкретно этой цели, и на это вот жалуется.

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

-w

Так аргумент-то валиден.

Нет, не валиден. На операцию «налить кипятка в чашку» была дана опция «арабика». Это не валидная опция для кипятка, это валидная опция для операции «насыпать пару ложек кофе».

Алсо, про gcc -L/some/path - по уму должен был бы ругнуться, если пути нет или если нет компоновки. Но gcc та ещё поделка.

Нет, не валиден. На операцию «налить кипятка в чашку» была дана опция «арабика». Это не валидная опция для кипятка, это валидная опция для операции «насыпать пару ложек кофе».

Если ты из арабики попытается сделать чай, получится не чай. А вот gcc мне выдаёт вполне рабочий объектный файл, который я могу слинковать.

Так что повторю вопрос: ты можешь без всратых метафор и фантазий про карательную кулинарию привести пример, в котором предоставление компилятору лишней информации, которую он проигнорирует, приведёт к ошибочному результату?

При чём тут комплиятор? Опции командой строки для пользователя, а не для программы. Компилятор в этом смысле точно такая же программа, как и любая другая, и вести себя должен точно так же. Хорошая программа должна уведомить тебя о совершённой тобой ошибке.

То, что ты хочешь забрутфорсить компилятор / программу всеми опциями, какие есть в мануале по нему / ей - явная твоя ошибка.

Ты создал тему, узнать какая логика скрывается за поведением шланга. Вот тебе ответ. Если он тебе не нравится - иди к разработчикам шланга и рассказывай им, какие они не правильные.

При чём тут комплиятор? Опции командой строки для пользователя, а не для программы.

Чо?

Хорошая программа должна уведомить тебя о совершённой тобой ошибке.

Но тут нет ошибки.

Ты создал тему, узнать какая логика скрывается за поведением шланга. Вот тебе ответ.

Да нет, это не ответ. Ты херню какую-то написал.

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

Думаешь, они чай из арабики заваривают там? Я всё ещё думаю, что это пример типичной сишной шизофрении, заключающейся в том, что если где-то можно поднасрать, то обязательно нужно поднасрать.

Я всё ещё думаю, что это пример типичной сишной шизофрении

Ну так и зачем вы себя насилуете и пишете на Си? Видно же, что вы ниосилили, бросьте.

Ну так и зачем вы себя насилуете и пишете на Си?

Приходится.

Видно же, что вы ниосилили

К моему вящему сожалению, осилил. В отличие от тех, кто тут клоунами разбрасывается.

Но тут нет ошибки.

Но тут есть ошибка. Если gcc её молча проглатывает, это не значит, что остальные компиляторы должны вести себя настолько же плохо.