C11, 6.6.10: IB: другие формы константных выражений: требуется дополнительная документация о соответствии

Почему это (кажется, что это) является обычной практикой для производителей компиляторов C не предоставлять конечным пользователям дополнительную документацию о соответствии о поведении, определяемом реализацией, в отношении «других форм константных выражений» (C11, 6.6.10)?

C11, 6.6.10:

Реализация может принимать другие формы константных выражений.

Этот факт приводит к следующим реакциям/отзывам (взято из разных источников):

ТАК пользователь М.М.:

Поставщик компилятора должен опубликовать документацию о соответствии, в которой перечислены выражения, которые он принимает в качестве констант, хотя я не смог найти эту документацию для MSVC. (оставьте комментарий, если можете!)

Источник: https://stackoverflow.com/a/62161678/9881330

Пользователь SO Кит Томпсон:

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

Источник: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618 (01.07.2015, 00:48:48 UTC)

Поскольку 6.6.10 относится к поведению, определяемому реализацией, и поскольку «каждая реализация должна включать документацию, описывающую ее характеристики и поведение» (стандарт C++, раздел 1.9), почему это не является общей практикой в ​​случае 6.6.10? Если кто-то здесь представляет какого-либо (промышленного) поставщика компилятора C, укажите причину / прокомментируйте ситуацию.

P.S. Возникновение вопроса связано с возможными проблемами переносимости, связанными с «другими формами константных выражений». Это сэкономит много времени, если конечные пользователи точно будут знать, какие «другие формы константных выражений» «принимаются реализацией» до написания кода (а не после, будучи удивлены проблемами переносимости ).

УПД. Примечание: «При использовании поведения, определяемого реализацией, я предполагаю наличие проблем с переносимостью, пока не будет доказано обратное». Если программный продукт планируется переносимым между N компиляторами, и все N компиляторов поддерживают одну и ту же языковую функцию, связанную с IB, которая полезна при написании кода, но считается поведением, определяемым реализацией, то почему бы не использовать ее? Единственный вопрос заключается в том, что нам нужно заранее знать, что эта языковая функция, связанная с IB, поддерживается всеми компиляторами N. (Да, мы можем эмпирически / экспериментально найти это, но в случае многих языковых функций, связанных с IB, это, вероятно, займет много времени. Лучше иметь официальное заявление от поставщика компилятора о том, что эта языковая функция, связанная с IB, поддерживается / не поддерживается.)


comment
При использовании поведения, определяемого реализацией, я предполагаю проблемы с переносимостью, пока не будет доказано обратное.   -  person Christian Gibbons    schedule 03.07.2020
comment
Поскольку компиляторы MSVC не соответствуют стандартам C, вы также не можете ожидать, что они будут соответствовать этому пункту. Но MS предоставляет обширную документацию.   -  person Weather Vane    schedule 03.07.2020
comment
Поскольку вы, кажется, цитируете ответы или комментарии на Stack Overflow, отредактируйте вопрос, чтобы включить ссылки на эти источники.   -  person 1201ProgramAlarm    schedule 03.07.2020
comment
Кто-то видимо нашел импл. определенное постоянное выражение в clang здесь: stackoverflow.com/questions/30158413/. Посмотрите в руководстве по clang, там упоминается об этом?   -  person Lundin    schedule 03.07.2020
comment
Одно из возможных объяснений очевидно: комитет по стандартизации не является вашим заказчиком, а реальным заказчикам такой документ не нужен. Так зачем тратить время и деньги на его написание, если это не улучшит продажи/принятие вашего компилятора?   -  person Nate Eldredge    schedule 04.07.2020