поскольку анализатор кода — штука зело полезная, то
обучил и её всяким новшествам. заодно потом впилил флаги «глобалы всегда считаются инициализироваными» и «заткнись по поводу неиспользованых аргументов».
на самом деле надо бы немного перепилить сам анализатор, чтобы он, например, не квакал «вложеная функция прочитала outer до записи в него», а сначала посмотрел внимательно. потому что сейчас он, похоже, сразу лезет во вложеную функцию — и, натурально, получается use before init. а надо лезть только когда в основной вызов встретился — тогда и правильные флаги будут готовы. то же самое и с глобалами, кстати.
то есть, сначала надо распарзить всё-всё-всё, а только потом начинать анализ; и делать его не по порядку объявлений.
а вообще, есть мнение, что некоторый анализ можно прямо в компилятор всунуть уже. его там не делали в своё время чтобы не тормозило, я так понимаю, и память не жрало. это уже неактуально. а обнаруживать простейшие «read unintialised value» можно и нужно. естественно, никакими не ворнингами, а полновесными еггогами.
с другой стороны, на такое есть стандартное возражение: «если добавить в компилятор проверки, и они не обнаруживают 100% случаев, то это хуже чем ничего: программист привыкает полагаться на компилятор, и пропускает что-то очевидное потом». ну, стандартный пример про «монтажников-высотников без страховочного пояса».
с третьей стороны — CP2 квакает, если в процедуре-функции нет ни одного RETURN. но спокойно затыкается, если есть хоть один, не пытаясь выяснить, все ли пути ведут к корректному RETURN. яркий пример того, что анализаторы авторы (ещё OP2) считали полезными, просто экономили на них ресурсы.
в общем, я считаю, что надо как минимум довести до ума проверку на наличие RETURN, и сделать «read uninitialised». кстати, второе позволит аннигилировать лишние начальные `p := NIL` по пути. то есть, компилятор сможет сначала потребовать, чтобы они были, а потом их просто поубирать. в итоге и красота, и немного эффективности.
делать это, натурально, надо отдельным модулем-анализатором (или даже несколькими), а не размазывать по коду парзера. 2023-й год на дворе, можно себе позволить несколько раз побегать по дереву.
конечно, это может поломать какой-то код (новые ошибки же!), но у меня всё равно Ultra Pascal теперь, могу себе позволить.
p.s.: имеет ли смысл создавать новую ветку для обсуждения нужности lint-style проверок непосредственно в компиляторе CP, или эту тему уже когда-то забили до смерти, и ну его?