Качество кода.

выключить безвредные ворнинги ты не додумался?

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

выключить безвредные ворнинги ты не додумался?

К сожалению, компилятор не в состоянии отличить полезные ворнинги от бесполезных.

x86-64 и x86-32 unit64_t это typedef на разные типы.

например, gcc на x86_64 требует, что в форматной строке для uint64_t использовался %lu, хотя должен быть %llu.

Для этого есть комментарий к данной строке, который пояснит, что это бага компилятора. А так же есть баг-трекер компилятора, в который нужно отправить сей баг.

(void) scanf(...)

Полностью поддерживаю. Мне подобный «грязный Гарри» два года жизни портил. Повезло ему, что за море-океаном обитал. Автору топика ещё хорошо, что его коллега сам баг выискивал, а нам приходилось по три дня и три ночи вместо разгильдяя баги закрывать перед релизом.

Думаю что полезным будет рассказать владельцам/начальникам о принципе «рокового автобуса» - если такого мастера собъёт автобус, то потом никто не сможет поддерживать продукт. Бизнес страховать нужно.

спасибо, капитан! Только это половые трудности разработчика компилятора, не находишь? sizeof(long long) == sizeof(int64_t) на обеих архитектурах.

Если да, что бы вы сделали с таким девелопером?

увлоить и нанять нормального, который понимает, что делать нужно не то что хочется, а то что надо

с точки зрения стандарта нифига не прав ты, потому что в стандарте нет упоминаний про %PRlu64, если уж мы о стандартах пошли.

Только это половые трудности разработчика компилятора, не находишь? sizeof(long long) == sizeof(int64_t) на обеих архитектурах.

Ну, справедливости ради, что касается PRIu64, см. стандарт на С99, «7.8 Format conversion of integer types <inttypes.h>», текст стандарта легко гуглится по словам C99 draft.

Теперь насчет половых трудностей разработчиков компиляторов:

В данном конкретном случае я считаю, что плохо, то что компилятор не выдает предупреждение на x86-32, а не то, что он выдает его только на x86-64. На это, видимо, есть основания (в особенности учитывая, что uint64_t является typedef-ом, и значит неотличим от встроенного типа на который сделан typedef), и переписывать пол-компилятора только для возможности верификации форматной строки в printf будет только полный дурак. Еще раз сформулирую свою мысль: ворнинг на x86-64 в данном случае следует рассматривать не как указание на то, что код не будет работать правильно на текущей платформе, а скорее как указание на потенциальные проблемы на других платформах. Я уже выше написал, как можно сделать без макросов PRIu64 так, чтобы это работало на любом компиляторе C, в котором есть long long из стандарта C99:

   uint64_t x = 1;
   printf("%llu\n",(unsigned long long)x);

(void) scanf(...)

Я знаю, что можно привести тип к void, но, ИМХО, это некрасиво и точно не повышает читаемость кода.

Винда под это определение попадает. Если бы она вообще не перделасвистела, то давно бы с нее свалили все.

program exited with code: 0

Поднимай зеркало на github, и поддерживай его - для начала просто исправляй ворнинги, при незначительных изменениях merge'и изменений из оригинала будут либо без конфликтов, либо конфликты будут тривиально разрешаться. Всячески рекламируй его с намёком на то что оригинальный разработчик не хочет мержить хорошие изменения. Напиши пару раз оригинальному разработчику с левых аккаунтов от якобы пользователей его софта у которых его версия глючит, а твоя нет и проси смержить изменения. Если аккуратно действовать, до него может допереть что он неправ. А вообще, зависит от размера софтины и запутанности кода - можешь попробовать поддерживать полноценный форк с новыми фичами.

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

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

Стараюсь исправлять все до единого warning. К сожалению, не всегда получается. Думаю, что пока от недостатка опыта.

Диагноз: быдлокодер

Был такой. Уволился сам. Самое ужасное - был формальным руководителем группы. Способ недопущения окончательного развала программного продукта:
svn/git/... copy .../trunk .../branches/stable -m '%developername%, пожалуйста не трогай эту ветку.'

После этого всей командой разработчиков были предприняты усилия к удалению мегафич, фиксации формата входных/выходных данных, исправлению мест, достойных олимпиад по программированию. В основном во внеурочное время.
А дальше представили в обход горе-руководителя-разработчика отчёт о том, сколько человекочасов тратится на поддержку схожих программ из соседних отделов и сколько у нас. В итоге руководство спустило разнорядку - довести время/человекозатраты до N часов....

Товарищ был поставлен перед фактом, что использовать будем stable, т. к. на поддержку trunk в заданном сверху режиме у него гениального времени как он сам говорит не хватит, а нам всем - мозгов и опыта. А stable мы вроде в сиду своих умений допилили и оно вроде неплохо работает.
Через два месяца товарищ уволился. По его словам ему стало скучно. И как-то так получилось, что даже нового программиста брать не стали, да и времени на новые проекты свободного оказалось навалом.

ok, насчёт PRlu пропустил. Я смотрел в описание printf, там этого нет.

повторюсь ещё раз: компилятор приводит uint64_t на разных архитектурах к разным типам: unsigned long long на x86 и unsigned long на x86_64. При использовании %llu код отрабатывает корректно на обеих платформах, но на x86_64 выдаётся бесполезный по сути warning, потому как sizeof(unsigned long) == sizeof(unsigned long long) == 8. Такие дела.

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

Если это невозможно - хотя бы не работать с ним (или уволить его, или уволиться самому). Warning'и говорят о грязи в мозгах - ничего хорошего из такого проекта по большому счету не получится.

Перфекционизм в виде Качественного Ремесла спасет этот погибающий мир!