Является ли неуказанным поведением сравнение указателей на разные массивы на предмет равенства?

Семантика для op== и op!= явно говорит, что сопоставление за исключением их истинностного результата. Поэтому вам нужно посмотреть, что определено для их истинностного результата. Если говорят, что результат неконкретный, значит, он неконкретный. Если они определяют конкретные правила, то это не так. Это говорит, в частности

Два указателя одного типа сравниваются равными тогда и только тогда, когда они оба равны нулю, оба указывают на одну и ту же функцию или оба представляют один и тот же адрес.

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

1. оба являются нулевыми указателями, и они равны друг другу.
2. оба являются указателями на один и тот же объект, и они равны друг другу.
3. они являются указателями на разные объекты, и они не равны друг другу.
4. по крайней мере один из них не инициализирован, а результат сравнения не определен (и, по сути, само сравнение может никогда не произойти — просто попытка прочитать указатель для выполнения сравнения приводит к неопределенному поведению).

При тех же ограничениях (оба указателя относятся к одному и тому же типу объекта) результат операторов упорядочивания (<, <=, >, >=) указывается только в том случае, если оба они являются указателями на один и тот же объект или на отдельные объекты в тот же массив (и для этой цели «кусок» памяти, выделенный с помощью malloc, new и т. д., квалифицируется как массив). Если указатели ссылаются на отдельные объекты, которые не являются частью одного и того же массива, результат не указан. Если один или оба указателя не инициализированы, у вас неопределенное поведение.

Однако, несмотря на это, шаблоны сравнения в стандартной библиотеке (std::less, std::greater, std::less_equal и std::greater_equal) делают все дают осмысленный результат, даже если встроенные операторы этого не делают. В частности, они необходимы для получения полного порядка. Таким образом, вы можете получить порядок, если хотите, но не со встроенными операторами сравнения (хотя, конечно, если один или оба указателя не инициализированы, поведение все еще не определено).

Поскольку существует путаница в семантике соответствия, это правила для C++. C использует совершенно другую модель соответствия.

1. Неопределенное поведение — это оксюморон, означающий, что переводчик НЕ ваша программа может делать все, что ему заблагорассудится. Обычно это означает, что он может генерировать код, который также будет делать все, что ему заблагорассудится (но это вывод). Там, где в Стандарте указано, что поведение не определено, текст на самом деле не имеет значения для пользователя в том смысле, что исключение этого текста не изменит требования, предъявляемые Стандартом к переводчикам.

2. Некорректная программа означает, что, если не указано иное, поведение транслятора жестко определено: требуется отклонить вашу программу и выдать диагностическое сообщение. Основным особым случаем здесь является правило одного определения, если вы нарушаете, что ваша программа плохо сформирована, но диагностика не требуется.

3. Определенная реализация налагает на переводчика требование, чтобы он содержал документацию, явно определяющую поведение. В этом особом случае результатом может быть Undefined Behavior, но это должно быть указано явно.

4. Unspecified — глупый термин, который означает, что поведение исходит из набора. В этом смысле хорошо определенное поведение — это всего лишь частный случай, когда набор разрешенных вариантов поведения содержит только один элемент. Unspecified не требует документации, поэтому в некотором смысле это также означает то же самое, что и реализация, определенная без документации.

В общем, стандарт C++ — это не стандарт языка, это модель для стандарта языка. Чтобы сгенерировать фактический стандарт, вы должны подключить различные параметры. Легче всего распознать ограничения, определенные реализацией.

В стандарте есть пара глупых конфликтов, например, законный транслятор может отклонить любую, казалось бы, хорошую программу на C++ на том основании, что вы должны предоставить функцию main(), но транслятор поддерживает только идентификаторы из 1 символа. Эта проблема решается с помощью понятия QOI или качества реализации. По сути, это говорит о том, что никто не собирается покупать этот компилятор только потому, что он соответствует требованиям.

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

На самом деле я предложил std::less как решение проблемы, заключающейся в том, что некоторые структуры данных требуют полного упорядочения ключей, а указатели не полностью упорядочены operator <. На большинстве машин, использующих линейную адресацию, less совпадает с <, но операция less, скажем, на процессоре x86 потенциально дороже.