Беззнаковый символ a [4] [5]; а [1] [7]; неопределенное поведение?

Я бы прочитал этот «информативный пример» в J2 как намек на то, что хотел стандартный корпус: не полагайтесь на тот факт, что случайно вычисление индекса массива дает что-то внутри границ «массива представления». Цель состоит в том, чтобы гарантировать, что все отдельные границы массива всегда должны находиться в определенных диапазонах.

В частности, это позволяет реализации выполнять агрессивную проверку границ и лаять на вас либо во время компиляции, либо во время выполнения, если вы используете a[1][7].

Это рассуждение не имеет ничего общего с основным типом.

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

Чтобы процитировать мой комментарий из нашего последнего обсуждения (Гарантирует ли C99, что массивы непрерывны? < / а>)

unsigned char *p = a[1]; 
unsigned char c = p[7]; // Strict aliasing not applied for char types

unsigned char c = a[1][7];

С 6.5.6 / 8

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

В вашем примере a [1] [7] не указывает ни на тот же объект массива a [1], ни на один за последним элементом a [1], поэтому это поведение undefined.

Под капотом, на реальном машинном языке, нет никакой разницы между a[1][7] и a[2][2] для определения int a[4][5]. Как сказал R .., это связано с тем, что доступ к массиву преобразуется в 1 * sizeof(a[0]) + 7 = 12 и 2 * sizeof(a[0]) + 2 = 12 (конечно, * sizeof(int)). Машинный язык ничего не знает о массивах, матрицах или индексах. Все он знает об адресах. Вышеупомянутый компилятор C может делать все, что ему заблагорассудится, в том числе наивную базу проверки границ в индексаторе - тогда a[1][7] будет вне границ, потому что массив a[1] не имеет 8 ячеек. В этом отношении нет разницы между int и char или unsigned char.

Я предполагаю, что разница заключается в строгих правилах псевдонима между int и char - хотя программист на самом деле не делает ничего плохого, компилятор вынужден выполнить "логическое" приведение типа для массива, чего он не должен делать. . Как сказал Йенс Густедт, это больше похоже на способ включить строгие проверки границ, а не на реальную проблему с int или char.

Я немного поигрался с компилятором VC ++, и, похоже, он ведет себя так, как вы ожидаете. Кто-нибудь может проверить это с gcc? По моему опыту, gcc гораздо строже в подобных вещах.

Я считаю, что причина, по которой процитированный образец (J.2) имеет неопределенное поведение, заключается в том, что компоновщику не требуется помещать подмассивы a [1], a [2] и т. Д. Рядом друг с другом в памяти. Они могут быть разбросаны по памяти или могут быть смежными, но не в ожидаемом порядке. Переключение базового типа с int на unsigned char ничего из этого не меняет.