Подавить предупреждение initialization from incompatible pointer type

-Wnone что-ли?

$ man man
$ man gcc

/-Wno-incompatible-pointer

-Wno-incompatible-pointer-types (C and Objective-C only)
           Do not warn when there is a conversion between pointers that have incompatible types.  This warning is for cases not covered by
           -Wno-pointer-sign, which warns for pointer argument passing or assignment with different signedness.

не?

Судя по документации просто "-w" — https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

Оказывается слона я и не заметил

#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-w"

...

#pragma GCC diagnostic pop

Нужно исправлять код, а не отключать предупреждения. Опция "-Werror" - обязательна.

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

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

Поздравляю! Вы приняты в говнокодеры.

Поздравляю! Вы приняты в говнокодеры.

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

Опция "-Werror" - обязательна

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

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

обычно же делают дебаг/релиз сборки, вдебаг включаешь опцию и пока пилишь еще и варнинги правишь (матерясь, конечно, но правишь)
в релизе же выключаешь опцию, а те майнтейнеры что для своих дистров лепят дебаг-сборки - ССЗБ

Я прослезился с твоего комментария. Есть же ещё адекватные люди.

Толсто.

Ну давай, продолжай барахтаться в говне. Зачем пытаться улучшать проект? Можно же тихо булькать в нем.

Да, говнокодерство, но кушать хочется.

Кушать хочется? Да, с таким подходом нормальную работу не найдешь - придется работать за еду и бояться увольнения.

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

+1. Хорошо для разрабов, но не для продакшена.

методично обмазывая код говном ты добьёшься только того, что кушать будешь всё меньше и меньше... пока не уволят по причине «стал медленно пилить новые фичи» или «в продакшене лезет много глюков»

А что Вы думаете о том что должен сделать ТС чтобы улучьшить проект. Не хочу нткого оскорбить, просто интересно.

Зачем пытаться улучшать проект? Можно же тихо булькать в нем.

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

Кушать хочется? Да, с таким подходом нормальную работу не найдешь - придется работать за еду и бояться увольнения.

Ты не поверишь в насколько крупных компаниях тот же подход применяется...

методично обмазывая код говном ты добьёшься только того, что кушать будешь всё меньше и меньше... пока не уволят по причине «стал медленно пилить новые фичи» или «в продакшене лезет много глюков»

Неа. Когда предлагаешь заказчику улучшить проект (выделить часы и деньги) он отвечает «нет, ни в коем случае».

А что Вы думаете о том что должен сделать ТС чтобы улучьшить проект. Не хочу нткого оскорбить, просто интересно.

Не нравится - возьми исправь. Сам так делаю и другим советую. Иначе проект закономерно скатится.

Просто есть реальный мир.

А я, конечно, в виртуальном живу.

Ну тебе допустим дали N часов на некую задачу и на нее реально надо N часов.

«Мне дали N часов на задачу»? Кто дал - это у тебя заказчик за тебя эстимейтит? Или тимлид не подозревает о необходимости рефакторинга/мелкого_улучшайзинга по мере развития проекта?

А сразу за ней дадут новую, ну или заказчика наотрез отказывается оплачивать рефакторинг. Просто есть реальный мир.

IMHO это упоротый проект, а не реальный мир.

Когда предлагаешь заказчику улучшить проект

Если заказчик не понимает, это просто вкладывается в эстимейты как накладные расходы и никто никого не спрашивает.

А я, конечно, в виртуальном живу.

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

«Мне дали N часов на задачу»? Кто дал - это у тебя заказчик за тебя эстимейтит? Или тимлид не подозревает о необходимости рефакторинга/мелкого_улучшайзинга по мере развития проекта?

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

Второй случай. Говоришь заказчику, что нужно N часов на задачу, а он говорит, что это он оплачивать не будет. И это для него дорого.

Третий случай. ты говоришь заказчику, что сисмтема в крайне плохом состояние и нужен месяц (чисто месяц без остальных задач) на ее улучшение. На что заказчик отвевчает или «нет» как «как-нибудь потом».

IMHO это упоротый проект, а не реальный мир.

Я работаю в оутсорсинге и мы сотрудничаем с мировыми гигантами (железными и прочими). В проектах с закрктым исходным кодом и не такое творится... А уволнять никто никого не будет. Всех все устраивает.

Если заказчик не понимает, это просто вкладывается в эстимейты как накладные расходы и никто никого не спрашивает.

Обычно заказчик понимеат, что фича которую я могу сделать за день не может занимать полтора месяца. Я конечно могу заоверэстимейтить до 3 дней, ну край до недели. Но когда тебе надо месяц или два, то это не сильно поможет. А если у проекта фундаментальные проблемы в архитектуре, то править по «чуть-чуть» не получается. Там надо взять и все переписать.

Вот я сейчас работаю на проекте где я программист и админ 10 серваков где эти приложения которые я разрабатываю крутятся. На деле система работает очень плохо - виноват хостер серваков. Я много раз говорил об этом заказчику, но он лишь охает и ахает, а делать ничего не хочет. Я даже переезд сервера mysql на новое жезело выбивал 4 месяца (отключение системы на день). Заказчик сам говорил, что систему лучше отключать ночью. Но заказчик жадный и оплачивать мне по x2 тарифу ночные работы он не хочет, поэтому система глючила и тупила почти пол года.

Обычно заказчик понимеат, что фича которую я могу сделать за день не может занимать полтора месяца. Я конечно могу заоверэстимейтить до 3 дней, ну край до недели. Но когда тебе надо месяц или два, то это не сильно поможет. А если у проекта фундаментальные проблемы в архитектуре, то править по «чуть-чуть» не получается. Там надо взять и все переписать.

Я не говорю про расклад «все бросить и месяц перефигачивать». Это - скорее удел доведенного до этого состояния проекта. Я как раз за то, чтобы постоянно тратить 20% времени на фоне на не_доведение проекта до такого состояния. И не анонсировать это заказчику, если он не понимает. Потому что «здоровье проекта» - это потом и мои нервы и мои проблемы, а не только заказчика.

Это если ты проект «с нуля» пишешь. Иногда проект тебе уже «достается».

Это если ты проект «с нуля» пишешь.

Или проект еще не пеешел в стадию «е**ный стыд» (мой случай, проекту 10+ лет).

тяжела жизнь аутсорсера... но это не повод подписываться на убитые в хлам проекты