4.2

Объём кодовой базы не играет роли. Во-первых, именно так обрабатывается каждый файл каждого проекта. Если бы Вы осилили настроить как я и говорил vim, syntastic, splint, то Вы бы заметили что анализ файла (любого, сишного, вне зависимости от объёма кодовой базы всего проекта в целом) производиться может как при открытии этого самого файла, так и при сохранении. Т.е., не важно кто и когда накосячил в коде, это будет заметно. Либо сразу, либо при сохранении... своих косяков. =) Так что, все разговоры о размерах кодовой базы и translation unit это тут ни о чём. Сразу лесом.

Во-вторых, какая разница в том, каков размер команды? Если в команде не в состоянии писать грамотный код, то лично я (да, я работодателем являюсь вдобавок) не собираюсь платить денег ни за что. И мне по барабану причины хреново сделанной работы. Мне похрен что ваша среда или редактор не позволяют искать ошибки сразу, а не через десять лет. Используйте ту, которая позволяет интегрировать нужные инструментальные средства и не снашайте мне мозг. Не можете (не хотите?) — на ... это вооооон туда.

Если бордель не исполняет план, то принято менять всё таки бл... «девок», а не мебель. К слову, в пределах данного тредя я вижу именно противоположный подход — «девки» на мебель жалятся. Компиль сишный, который мебелью и является, предсказуемо помалкивает. =)))

Я вот тут ответил.

Человеческая замена C для своих задач (комментарий)

=)))

Но всё таки добавлю. Про финализаторы. =)

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

Теперь ненужные Вам шкурки будут занимать минимальный объём в вашем мусорном ведре. =)))

Так что, все разговоры о размерах кодовой базы и translation unit это тут ни о чём. Сразу лесом.

Походу, в своих предположениях я оказался близок к истине, раз вы демонстрируете упорное непонимание очевидных вещей.

Во-вторых, какая разница в том, каков размер команды?

Большая.

Вам, вероятно, просто ни разу не приходилось с этим фактором столкнуться.

Тоже с теоремой Райса не знакомы? Линтеры могут находить только частные случаи ошибок. В каких-то нетривиальных случаях они могут не сработать. Но в тривиальных случаях goto cleanup тривиально заменяется RAII. В результате имеем смесь корректного рукописного RAII с потенциально некорректным кодом. И ни визуально, ни линтером эти случаи не отличить. Если использовать goto cleanup в нетривиальных случаях, это хотя бы привлечёт внимание (даже если забыть написать комментарии).

Да нет, знаком.

Тоже с теоремой Райса не знакомы?

Почему же, знаком.

Линтеры могут находить только частные случаи ошибок. В каких-то нетривиальных случаях они могут не сработать.

Вообще-то, в методологии разработки TDD есть уже все ответы на такого рода вопросы. Если тестами покрывать код ещё до его существования, то крайне велика вероятность того, что такие нетривиальные случаи будут очевидны ещё на этапе проектирования или покрытия начальными тестами (которые пишутся, подчеркну) ещё до кода продукта. И станут вполне себе тривиальными.

Но в тривиальных случаях goto cleanup тривиально заменяется RAII.

Поэтому RAII и ненужен.

В результате имеем смесь корректного рукописного RAII с потенциально некорректным кодом. И ни визуально, ни линтером эти случаи не отличить. Если использовать goto cleanup в нетривиальных случаях, это хотя бы привлечёт внимание (даже если забыть написать комментарии).

Нет. =)

В, дайте угадаю, D этого позорного «goto» нет? =)))

Не угадал, есть https://dlang.org/spec/statement.html#GotoStatement да и не может не быть D же пишет старый сишник по сути.

На самом деле, это просто очередной миф, тянущийся года с 1968-го, когда «велийкий Дийкстра» сказал что goto «позорен»

Не писал, а главное не разбирал ты код на старом бейсике еще с номерами строк и ничем незамутненной лапшой из goto :)

Вообще даже в си кроме двух случаев выход из глубоко вложенных циклов и для очистки ресурсов goto нафиг не нужен.

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

По ходу, Вы просто не понимаете о чём говорите.

Объясню проще.

Походу, в своих предположениях я оказался близок к истине, раз вы демонстрируете упорное непонимание очевидных вещей.

В несомом Вами бреде ни каких очевидных вещей не обнаружено.

Причина проста:

Большая.
Вам, вероятно, просто ни разу не приходилось с этим фактором столкнуться.

Вы не работаете с промышленным (индустриальным) созданием кода. У кода есть два состояния. Либо всё работает корректно, либо всё не работает. Либо код написан качественно, либо нет. Либо программисты применяли все возможные инструменты улучшения качества кода, либо они занимались словесным онанизмом на заданную тему. Т.е., либо команда осиливает работать как единый механизм, либо это просто толпа кодерастов. Причём, необучаемых, т.к. подсмотреть один у другого приёмы, позволяющие минимизировать временные затраты, они не в состоянии. Размеры толпы не интересны. Они могут продолжать сидеть и хныкать про «плохой, злой и ненужный» С.

На деле они просто потеряны для эволюции. Они требуют эволюции от инструмента, но не готовы учиться и эволюционировать сами. Вы там, помнится, мне на возраст пеняли? Я не ошибся?

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

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

Могу со стопудовой уверенностью сказать: говно тот ЯП, где нет goto!!!

Методики надо изучать.

А не отмахиваться от «ненужной теории». Если бы был методически корректный подход, то чаще всего не было бы проблем. Кстати, Вы же поминали про теорему Райса? Ну и как там с нетривиальными случаями будет в RAII? Они волшебным образом все станут тривиальными?

Но тогда что тривиальнее (вспоминая наш с Вами более ранний разговор в данной теме) чем сисколл, я просто даже и не знаю.

Вообще да.

Вообще даже в си кроме двух случаев выход из глубоко вложенных циклов и для очистки ресурсов goto нафиг не нужен.

+1.

На стаду долб... «уважаемых коллег» не объяснишь этого. Они увидели «goto», слышали где-то что он ненужен и понеслось...

У кода есть два состояния. Либо всё работает корректно, либо всё не работает.

Ох ё, детский сад, младшая ясельная группа.

Это в HelloWorld-е на 100 строк вы можете быть уверены на счет корректно или некорректно. И то, если там многопоточности нет в принципе.

Расскажите, как вы достигаете такой уверенности для программы в 100KLOC? А в миллион?

И во что обходится достижение этой уверенности? По времени, людским ресурсам, деньгам...

Теорема Райса говорит о произвольных программах. Использование RAII позволяет сузить множество допустимых программ. То есть это уже не произвольная программа, а программа из синтаксической корректности которой следует присутствие семантического свойства.

Проверить, что это семантическое свойство соответствует спецификации, - это уже задача программиста. RAII, естественно, не будет читать документацию, чтобы проверить, что ресурсы освобождаются в нужном порядке, но от ошибок, где goto cleanup_a перепутали с goto cleanup_b и т.п., защитит на 100%.

Опять-же, то, что с помощью RAII не удаётся получить нужную стратегию освобождения ресурсов, укажет на то, что случай нетривиальный и на него нужно обратить особое внимание.

Есть подозрение, что Moisha_Liberman работает с программками объемом в несколько KLOC без внешних зависимостей. Поэтому прогона линтера на всего одном translation unit ему вполне достаточно

А это тут причём? Вы когда с линтерами последний раз имели дело? Его встраивают и на машинах разработчиков, и в git hook, и в CI, и куда только не. При этом имеется возможность многопоточного сканирования.

А это тут причём?

При том, что мойша выше описывал, как у него линтер настроен.

А, сорри. Перепутал личный выпад в стороны Мойши, с выпадом в сторону линтеров.

Вообще даже в си кроме двух случаев выход из глубоко вложенных циклов и для очистки ресурсов goto нафиг не нужен.

Причём глубоко вложенные циклы кроме редких случаев принято избегать. Чему способствует принятое соглашение о ширине строки в <=80 символов.

Воу-воу, вы внезапно полюбили питон? Потому что https://github.com/snoack/python-goto

Я полностью согласен, на си невозможно писать без питона.

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

Грубо говоря, есть resouce.c/h, в котором что-то вроде:

some_resource * alloc_resource() {...}
void dispose_resource(some_resource * r) {...}

Есть data.c/h, в которых что-то вроде:

struct app_data {
  ...
  some_resource * resource;
};

app_data * make_app_data() {
  app_data * result = malloc(sizeof(app_data));
  result-> ...;
  result->resource = NULL;
}
void free_app_data(app_data * data) {
  ... // вызов dispose_resource(data->resource) забыли сделать.
  free(data);
}

И есть какой-то controller.c/h, в котором:

app_data * data = make_app_data();
data->resource = alloc_resource();
...
free_app_data(data);

Или какие-то линтеры факт отсутствия вызова dispose_resource в data.c ловят?

Нет. Не так.

они не способны обнаруживать ситуации, когда в одном TU аллоцируется какой-то ресурс и каким-то образом (через возвращаемое значение, например) отдается на владение в другой TU.

Если у Вас корректно подключены хидеры, то splint обнаружит эту ситуацию.

Или какие-то линтеры факт отсутствия вызова dispose_resource в data.c ловят?

Сперва Вам прилетит от splint за unused function, потом, если проявите завидную настойчивость и забъёте на предупреждение, и от компиля прилететь должно. Но можно не останавливаться и получить вполне закономерную утечку. =)

Да.

Чему способствует принятое соглашение о ширине строки в <=80 символов.

Тот же kernel coding standard штука вполне разумная. Там ещё и таб в восемь символов прописан.

Теорема Райса...

Совершенно без разницы что она говорит, её, кстати, ещё и доказывать надо. В любом нетривиальном случае она будет справедлива что для случая с RAII, что для случая без RAII. Так что, говнокод посредством RAII не поправить.

А вот что аксиоматично, так это то, что грамотно подобранные инструменты и грамотное же следование методикам, резко снижают попаболил в единицу времени.

Да Вы что? Серьёзно?

Это в HelloWorld-е на 100 строк вы можете быть уверены на счет корректно или некорректно. И то, если там многопоточности нет в принципе.

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

В противном случае, Вы видимо хотели бы оказаться в числе тех пассажиров парочки Boing MAX котрые весьма неловко «прилегли» из-за ошибок в софте, я правильно думаю? Странно конечно, но в «моё время» как-то были более требовательны к качеству кода.

Нет? Ну как же так? Там же наверняка не 100 строк хелоуворлда...

Расскажите, как вы достигаете такой уверенности для программы в 100KLOC? А в миллион?

Да я, собственно, уже всё рассказал. Мне остаётся только добавить что если Вас за пять (или сколько там лет) не научили в ВУЗе, то здесь, на просторах форума в качестве Вашего послевузовского обучения это уже мне не интересно.

«Какой закон? Напирай плотней! Оставь! При чем здесь Ломоносов – Лавуазье? Главное, напирай плотней!»

Всё доказано, ещё в 1951-м году. Но напирать плотнее тоже не помешает - да.

Си говно, а его адеаты не ведают границ своего безумства.

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

Это новый способ сказать «хеловордщик». Спешите видеть.

То есть, Вы сразу и на берегу закладываете то, что в любом софте есть ошибки?

Вообще-то это объективная реальность, данная в ощущениях.

Я не настолько смел.

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

Я, например, считаю что в любом или практически любом софте есть уязвимости, но не ошибки.

Да-да. Если вы обосрались, но назвали это «преждевременное испражнение», то это уже и не обсер вовсе.

В противном случае, Вы видимо хотели бы оказаться в числе тех пассажиров парочки Boing MAX котрые весьма неловко «прилегли» из-за ошибок в софте, я правильно думаю?

Пациент демонстрирует явные проблемы с логикой.

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

Если уж приводить в пример именно программную ошибку, так лучше Ариан 5. Вот там вполне себе точно доказанная вина софта в аварии.

Это новый способ сказать «хеловордщик».

Вообще-то я намекал на то, что софт для 8-ми битовых контроллеров, разрабатываемый в мелкой частной лавочке, вряд ли может сравниться по объему с какими-нибудь пусть даже и небольшими десктопными приложениями (не говоря уже про другие ниши).

Но ваша интерпретация мне тоже нравится.

Не только: http://www.kohala.com/start/papers.others/knuth.dec74.html

Вы просто не писали на ML-подобных языках.

У питона отвратный интерфейс.

Вы просто не писали на ML-подобных языках.

ML-подобные языки как-то магически защищают от опечаток вида «a+1-n» вместо «a+n-1»?

Или в ML-подобных языках есть какая-то защита от того, что в коде будут учтены не все условия, заданные в спецификации/ТЗ?

Не говоря уже про то, что мойша говорит не про Хаскелль или ОКамл, а про Си.

Если у Вас корректно подключены хидеры, то splint обнаружит эту ситуацию.

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

Сперва Вам прилетит от splint за unused function, потом, если проявите завидную настойчивость и забъёте на предупреждение, и от компиля прилететь должно.

То, что вы говорите прозрачно намекает на то, что вы сами-то этим splint-ом пользуетесь как-то не так. Или не для того. Ибо, если скормить splint-у вот такой вот код:

data.h:

#ifndef DATA_H_
#define DATA_H_

#include "resource.h"

struct app_data {
	int a;
	long b;
	/*@out@*/ /*@null@*/ struct some_resource * resource;
};

struct app_data * make_app_data();
void free_app_data(/*@only@*/ struct app_data * data);

#endif

data.c

#include "data.h"

#include <stdlib.h>

struct app_data * make_app_data() {
	struct app_data * result = malloc(sizeof(struct app_data *));
	if(NULL == result) abort();
	result->a = 1;
	result->b = 2;
	result->resource = NULL;
	return result;
}

void free_app_data(/*@only@*/ struct app_data * data) {
	free(data);
}

То splint data.c выдаст такое вот предупреждение:

Splint 3.1.2 --- 03 May 2009

data.c: (in function free_app_data)
data.c:15:7: Only storage data->resource (type struct some_resource *) derived
                from released storage is not released (memory leak): data
  A storage leak due to incomplete deallocation of a structure or deep pointer
  is suspected. Unshared storage that is reachable from a reference that is
  being deallocated has not yet been deallocated. Splint assumes when an object
  is passed as an out only void pointer that the outer object will be
  deallocated, but the inner objects will not. (Use -compdestroy to inhibit
  warning)

Finished checking --- 1 code warning

Что, безусловно, лучше, чем я ожидал.

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

Когда хвастают длиной МПХ, принято весомые доказательства приводить. А то будет как в том анекдоте: «а вы тоже говорите, что по 3 раза на дню!»

Ты так и не показал свой суперкод!

А то будет как в том анекдоте: «а вы тоже говорите, что по 3 раза на дню!»

Разница в том, что я и не говорю.

Ты так и не показал свой суперкод!

В открытом доступе нет моего прикладного кода, который бы решал какую-то прикладную задачу (так уж получилось, что такие вещи всегда писались за деньги). Есть только весьма специфический и библиотечный, написанный не только мной. Если интересно именно то, что написано на 100% лично мной, то можно посмотреть сюда или сюда (емнип, чужих правок там нет).

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

Не говоришь, но всех хаешь!

Как у программиста может не быть тонны кода на гитхабе? Хоть тех же сниппетов... И если даже код за деньги пишется, ты ж NDA не подписываешь!!! Или все совсем печально? Тогда я прав насчёт тождества работы программиста и проститутки: оба себе не хозяева, а типичные рабы!!!11

Как у программиста может не быть тонны кода на гитхабе?

Если начал программировать очень задолго до появления гитхаба, и плюс используешь не git, а hg или svn.

Тогда я прав насчёт тождества работы программиста и проститутки: оба себе не хозяева, а типичные рабы!!!11

У астрономов вроде еще хуже, шансов работать как мелкий частник или фрилансер совсем не видно.

Не говоришь,

Не говорю. Так что ваши «предъявы» мимо.

но всех хаешь!

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

Как у программиста может не быть тонны кода на гитхабе?

Лехко! Изрядный процент программистов вообще не пишет код вне работы. Я, например, потерял желание и возможность писать код просто для души, безотносительно рабочих задач, еще за несколько лет до появления git и github-а.

Хоть тех же сниппетов...

Эдди, большое количество нужных вам сниппетов напрямую указывает на несоответствие уровня вашего языка и сложности решаемых вами задач. Тут уже выше были примеры того, как взять язык повыше C (вроде D или C++) и писать в разы меньше кода, да еще и более надежного.

Тогда я прав насчёт тождества работы программиста и проститутки: оба себе не хозяева, а типичные рабы!

Это относится к любому наемному труду.

Работал над сишным продуктом. Лично наладил CI с тестами, линтами, санитайзерами и пр. Работали там люди с большим опытом. Код писали нормальный для Си. Ваш goto cleanup использовали. Код ревью друг друга делали. И пр.

Как вы думаете, избавило нас это от проблем с освобождением ресурсов, с переполнением буферов и пр.?

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

Но по сравнению с любым из моих крестовых продуктов, так багов было в разы больше. И все равно многие уходили на прод.

Кстати, как у вас с тестированием? Может вы баги плохо ищите?

А вот, кстати говоря, забыл сразу спросить:

Если в команде не в состоянии писать грамотный код, то лично я (да, я работодателем являюсь вдобавок) не собираюсь платить денег ни за что. И мне по барабану причины хреново сделанной работы. Мне похрен что ваша среда или редактор не позволяют искать ошибки сразу, а не через десять лет. Используйте ту, которая позволяет интегрировать нужные инструментальные средства и не снашайте мне мозг.

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

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

Напирай-не напирай...

Но говнокод RAII не поправить. Тут нужна не теорема, а методика, позволяющая определить границы, за пределами которых ситуация перестаёт быть тривиальной (или наоборот, становится таковой). А дальше уже остаётся решить что будем делать с нетривиальными ситуациями. Будем их обрабатывать и как? Так что, тесты, TDD и вот это вот всё.

Всё остальное не работает. Проверял лично. =)

Ну тогда не третьте на себя ресурсы планеты.

Вообще-то это объективная реальность, данная в ощущениях.

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

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

Мне хорошо в Linux годика так с 95-96го. Видел более чем до хера. Даже знаю что вот в D без поганого goto не обошлись. Видел и слышал более чем до хера сказок про очередные языки, объявляемые очередным нашим всем. Но вот Ваше столкновение с реальностью в виде splint меня не скрою, позабавило. =)))

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

ЩИТОПРАСТИТИ??? В означенных авариях виновен не какой-то один «незадублированный датчик», там целая подсистема боролась с пилотами. И победила. Что в достаточной мере показывает как достаточно сложная система, реализованная и применяемая без должного анализа (да-да-да, Ваши пресловутые миллионы строк кода) является причиной гибели людей.

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

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

Не понял?

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

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

Но Ваша реакция на результаты работы splint меня позабавила. =))) Понимаю, внезапно, да.

Но если вы затаскиваете в свой проект стороннюю либу, которая splint-ом не проверялась, то утонете под потоком предупреждений splint-а.

Т.е., до Вас начало постепенно доходить откуда берутся все эти патчи безопасности? И почему патчи зачастую пишутся совершенно другими людьми, нежели авторы исходной библиотеки? Да сегодня день открытий, не иначе! =)))

Или Вы всерьёз думаете что если Вы затаскиваете говно в свой код, то Ваш код не станет от этого говном? Уверяю Вас, что нет ни какой зависимости от величины той ложки говна, которую Вы добавляете в бочку мёда, вся бочка станет говном. Даже от чайной ложечки.

Не задерживайтесь здесь. Не нужно.

Это, такой вежливый способ сказать «сдохни, тварь!»?

Видимо, я вам на какую-то мозоль любимую наступил, раз вас так разорвало.

Что в достаточной мере показывает как достаточно сложная система, реализованная и применяемая без должного анализа (да-да-да, Ваши пресловутые миллионы строк кода) является причиной гибели людей.

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

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

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

Если вас и пример с Ариан 5 не убедил, то поинтересуйтесь случаем с Therac-25.

А еще, не будь вы таким клиническим случаем, то могли бы поинтересоваться работой под названием «Making reliable distributed systems in the presence of software errors» известного в узкий кругах Джо Армстронга. И по мотивам чего эта работа была написана.

Я что, где-то писал что я здесь нанялся работать пересказчиком интернетов для Вас?

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

А уж будете Вы пользоваться и как, это Ваше дело. Даже если не будете, то это опять-таки Ваше дело.

Этими общими и пустыми словесами вы убого пытаетесь заболтать простую вещь: в C для контроля за детскими ошибками вам нужно добавлять в свой арсенал дополнительный инструмент и, при этом, размечать свой код аннотациями, которые не имеют отношения к стандарту языка. Посему такой код будет крайне чувствителен к методике разработке и аккуратности разработчиков.

Тогда как в C++ вы могли бы использовать unique_ptr, а в Rust-е Box, и вас такой проблемы не было бы в принципе. И все это в рамках одного и того же языка, без привлечения других инструментов, без чувствительности к тому, что кто-то не будет прогонять линтер или юнит-тесты перед коммитом.

Не говоря уже про использование GC.

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

Взоржахом аки конь стоялый! =)))

Эвона как Вас splintом-то звидануло! =)))

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

Затем что даже на естественных языках люди допускают ошибки и опечатки. Давайте выкинем на фиг из компиляторов и интерпретаторов синтаксические анализаторы в принципе. На фиг там они вообще?

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

На каком языке можно написать что-либо без ошибок? Приведите примеры? С++? Rust? Python? D? Ну? Смелее...

То, что в других языках нет подобных качественно проработанных инструментальных средств показывает только то, что языки слишком молоды и не накопили должной теоретической базы для формирования алгоритмов поиска ошибок и поддержки программиста. Либо это Вы о них ни чего не знали, не знаете и знать не желаете. Такого тоже исключить нельзя.

Например. Зачем питоновцам тот же pylint? Для Go вот тут кучка — https://github.com/golangci/awesome-go-linters Для других языков не искал, лень. Но скорее всего тоже чего-нибудь найдётся.

Проблема тут не в С и не splint, результаты которого Вас вполне предсказуемо удивили. =))) Проблема в том, что Вас за пять лет Вашего прогуливания армии в институте, Вы оттуда не вынесли никаких методик работы с кодом за исключением одной — открыть редактор и кодерасить-кодерасить-кодерасить. Не Вы один такой. Но это уже... Да и хрен бы с ним, в общем.

В общем, удачи и узбеков. Творческих. =))) Потому как это не столько программирование у Вас, сколько табличка «кодерашу за еду».

Ваша профнепригодность очевидна. Да.

Если мне нужно не только махнуть рукой в сторону инструментального средства, а ещё и научить Вас с ним работать. Расписать и рассказать как именно надо оформить код.

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

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

Ваше послевузовское образование в мои функциональные обязанности не входит и оно мне не интересно. Я даже не спрашиваю в каком ГПТУ Вам выдали справку о верхнем образовании («высшим» это рука не поворачивается назвать), где Вас так изуродовали образованием, что простейшие и очевидные вещи типа скачать и прочесть документацию вызывают такую боль и сложности.

Мне лень. Мне не интересно. Оставляю Вас с Вашим инфантилизмом в компании. =)))