Как стандарты C и C++ предписывают вам действовать в ситуациях, которые ими не охвачены?

Боюсь, эти слепые пятна остались в памяти разработчиков компиляторов.

Эмпирическое правило: избегайте попадания кода в такие ситуации.

Обычные авторы кода гораздо чаще сталкиваются с ошибками или ошибками производительности в компиляторах или стандартных библиотеках, чем в языковых стандартах. По моему опыту, вероятно, в 10 раз. Так что, особенно с точки зрения людей, пишущих код приложения, я думаю, что эти вопросы несколько неуместны. Но они, безусловно, интересны для разработчиков компиляторов и библиотек.

Поскольку, как вы написали, старые стандартные издания отозваны, я не думаю, что ISO даже предлагает какие-либо возможности для официальных исправлений к ним и считает их неуместными. Отчеты о дефектах включены в следующий стандарт или TC (что WG21 сделала, например, для C++03, но, похоже, больше не делает).

@user17732522 Официального заявления типа «по всем вопросам, не охватываемым этим стандартом, обратитесь к более поздним документам» комитета по стандартизации или самой ISO было бы более чем достаточно. Это полностью решило бы проблему.

@DmitryD.Chernov Стандарт C90 официально помечен как «Отозван» на той самой странице, на которую вы ссылаетесь.

@DmitryD.Chernov Я сомневаюсь, что это соответствует правилам и процедурам ISO. Поскольку ISO является организацией, они также строго определены. Но я ни в коем случае не эксперт в этом.

@AndrewHenle Да, я знаю. Мой вопрос касается проблемы, которая, по-видимому, является общей для всех стандартов C и C++, когда-либо опубликованных ISO.

@cher-nov, ваш последний комментарий подсказывает мне, что, возможно, вы имеете в виду конкретный (предполагаемый) языковой недостаток и пытаетесь понять, как поступить с этой информацией. Если да, то я бы рекомендовал задать новый вопрос, в частности, о вашем предполагаемом недостатке.

@JohnBollinger Нет, под «проблемой» выше я имел в виду отсутствие в стандартах пояснений о подходах к их правильной интерпретации, особенно в тех случаях, когда о чем-то умалчивают. В известной степени это даже философский вопрос, в духе лингвистического поворота и литературоведения.

Спецификации языка объясняют, как ведут себя соответствующие реализации соответствующих языков. Они ничего не говорят о том, как вам следует себя вести. - Определенно, но сами реализации не субъективны; они также написаны программистами-людьми. Это то, что я имел в виду.

В спецификации не обязательно явно указывать, что поведение не определено. C, в частности, определяет «неопределённое поведение» следующим образом: <...> — Согласен, но я скорее имел в виду поведение, которое не должно быть неопределённым ни при каких обстоятельствах, потому что в противном случае это сделало бы язык частично несогласованным. Другими словами, это проблемы, по которым стоит подать отчет о дефекте, если затронутый стандарт все еще действует.

@cher-nov Я думаю, что лучшим примером того, что вы имеете в виду, было бы прямое внутреннее противоречие в стандарте, который для C++ определенно существует, и я был бы удивлен, если бы его не существовало в C. Например, из текущего стандарта C++ вы можете сделать вывод что соответствующая реализация должна завершать следующую программу кодом выхода 0: struct A{};struct B:A{};struct C:A{B b;};C c;int main(){return (A*)&c == (A*)&c.b;}; Но вы также можете сделать вывод, что она должна заканчиваться кодом выхода 1.

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

@cher-nov, «сами реализации не субъективны; они также написаны программистами-людьми. Вот что я имел в виду». -- Я не вижу различия, которое вы пытаетесь провести. Спецификации также не говорят разработчикам языка, что делать. Скорее они предоставляют стандарт, по которому можно оценивать работу разработчиков: либо «это соответствующая реализация C (или C++)», либо нет. И поскольку вы утверждаете, что разработчики могут не чувствовать себя обязанными предоставлять соответствующую реализацию, я не вижу пути оттуда к спецификации, указывающей кому-либо, что делать.

@cher-nov, относительно «поведения, которое не должно быть неопределенным ни при каких обстоятельствах, потому что в противном случае это сделало бы язык частично несовместимым» - если спецификация оставляет данное поведение неопределенным, то это не может вызвать какое-либо несоответствие в языке, как он определен. Как может спецификация, не предъявляющая никаких требований, сделать что-то противоречивым? И поскольку вы конкретно спрашиваете о поведении, которое явно не объявлено неопределенным (или не определено или не указано в реализации), не может быть даже противоречия относительно того, является ли оно на самом деле неопределенным.