Та там всего три абзаца, из которых следует вывод, что имя массива почти всегда (за исключением, например, sizeof правила для которого обговорены в отдельном пункте) преобразуется в указатель на первый элемент массива причем того же типа. С дальнейшими правилами действий для такого указателя.
Таким образом из выражений *((E2+5)+E1), ((E2)+5+(E1)) и подобных невозможно что-либо утверждать про размерности массива.



Никаких указателей на не массив и прочее.
Так название главы означает что оператор [] применим только для доступа к элементам массива.

В стандарте есть явные определения логики интерпретации применения [] к указателю на не массив и на не элемент массива?


Никаких <почти всегда> оттуда не следует. Тем более, что что-то там преобразуется. Смысл написанного: <допускается писать такую конструкцию с такими-то вариантами, которая будет истолкована так...>

Нет. Оператор [] значится как postfix-operator и определен для "array subscripting". Это признак массива.




"Почти всегда" следует потому в случае оператора sizeof, согласно которому имя_массива преобразуется в тип "массив заданной размерности",
в остальных случаях имя_массива преобразуется в &имя_массива[0].

Это по шагам можете объяснить?
Мне понятны варианты когда а[0][24] идентичен a[1][19] и идентичен a[2][14] и т.д. Если не обращать внимание на варнинги компилятора. Но a[24][0] каким образом-то?


index1[index2][array_name] и index1[index2][index3][array_name] тоже разрешены? Если да, исходя из каких формулировок?


То есть разрешение применения [] к любому указателю на непустой тип даёт именно первый абзац главы <6.5.2.1 Array subscripting> ? object type определён как любой, за исключением void? В стандарте есть суммарный раздел об авто-преобразованиях? Или надо шерстить весь стандарт чтобы откопать однозначность?

Видимо отсюда и растут ноги у названия "подписка". Страннейшего, для необкуренных мозгов. Обозвали бы "индексация" и уловка с авто-подменой была бы недоступна.

В посте 40 я ошибся, в цитате:
<И уже когда к этому аргументу будет приплюсовываться число 5, то оно, проще говоря, должно быть (наиболее вероятно по вышеобозначенной инфе) индексом следующей (второй) размерности.>
т.к. на следующую размерность не перейти, без применения оператора * в вариантах со сложением.



Ну бред же. Для компилятора имя массива - это lvalue (кратко - объект в памяти). К нему можно применить амперсанд. &имя_массива[0] - это rvalue, к нему (здесь будет второй раз) амперсанд не применим. И для (простейше определённого) многомерного массива array_name[0] есть тоже lvalue. А, согласно этой цитаты, выражение &(array_name[0]) давало бы ошибку. Т.к. выражение в скобках, являющееся массивом авто-преобразовывалось бы в указатель. Хотя, корректней писать в <rvalue-указатель>. Всё это потверждает, что и rvalue с типом указатель на массив и lvalue с типом массив существуют без всякого sizeof, в них определена характеристика размера (для размерных), компиляторы поступают вполне разумно её проверяя на этапе компиляции, а что мешает копировать массивы выражениями вроде a=b - непонятно.

В языке должна быть ясность очерёдности исполнения авто-преобразований и операторов. Например: авто-преобразования применяются компилятором в самый последний момент исполнения операторов. И не должны менять приоритеты операторов при определении очерёдности их исполнения. Хотя, с таким неполным стандартом, если по нему ясность поведения будет не определена, то, наверное, судить придётся по каким-то ещё документам, например от выдумщика языка. А то появится несогласующийся с ранее написанными правилами футбол между операторами, операндами и авто-преобразованиями. (в этой ветке я ранее писал аргументов, но терминологически точнее, видимо, операндов для операторов и аргументов/параметров для функций)

Пытаясь как-то оправдать логику выдумщика и потом стандарта, когда на начальном этапе массив (array object по терминологии главы 6.5.2.1) казался избыточным и работу с массивами НАДО БЫЛО организовывать через указатели и операторы +-, которым был непринципиален порядок разношёрстных операндов, мне самому любопытно, на какой развилке не туда свернули)))
Упд. Именно такая историческая цепь прослеживается при чтении стандарта, когда оператор [] определяется текстовым примером через ранее определённые выражения.

Согласно 1-му пункту "подписки" это нелегально. Потому что в части выражения "index1[index2]..." один из этих индексов должен быть "pointer..."



Если по шагам, то этот пример я хотел привести намного раньше, когда Вы в ((E1)+(E2)+5) предлагали видеть в 5-ке индекс второй размерности.
Но я ошибочно начал тавтологию про типоразмеры. Но так как мне показалось, что мы толчем воду я его и привел с опозданием.

Вы правы, если продолжить ряд , то должны прийти к правильному решению похожему на a[24][-64].
Или сразу применить формулу, по которой добавляя число к первому индексу, мы должны отнимать это число, умноженное на 5 от второго. 5 и выступает в качестве типоразмера. Имхо, пример хорошо иллюстрирует рекурсивность правила для многомерных массивов.



Я не знаю стандарт достаточно хорошо. Помню в свое время всем отделом шерстили именно по указанной теме.
Но похоже, что действует принцип: "разрешено все, что не запрещено". Поэтому использование "подписки" для указателя вполне законно.

Только я не уверен, что термин в стандарте эквивалентен нашему пониманию "подписки".


Ну я условно, для краткости, чтобы не писать присутствующее в каждом посте "pointer to....".



Но почему Вы считаете, что они свернули не туда? Они реализовали "ассемблерные возможности" на высоком уровне. И это есть хорошо.
И не дай бог они повернут туда: зачем нам третья java, или четвертый шарп?

Пошла 4 страница трёпа вокруг массива/указателя... Ещё 6 страниц и можно ожидать переходы на личности и мерянье пиписьками
Пошёл за попкорном

Как буд-то родился "кошмар на улице си" index[array]. Не прочитав всю кучу документов точно и не разберёшься.

Полноценный перевод этого мутного термина я не знаю. В каких-то словарях компьютерных терминов его кастрируют до <индексация>. Но в общеупотребительном смысле это слово более многогранное. Со смыслами <одобрить>, <согласиться>. Пока (если лучше версию не увижу), наверное буду считать в Си "признать массивом и индексировать". Но у буржуев есть какой-то схожий термин "superscripting" (superscription-надпись, в общеупотребительном аглицком), которе вместе (теоретически наверно) могут как-то обозначать вариации индексаций "вглубь" (для массивов) или наружу (для указателей). Но с такими тонкостями толкования я пока не пересекался.

Мутность такая же, как при переводе термина bitwise (complement), о котором когда-то спорили.

Так буквальный перевод subscript и означает индекс (нижний или верхний).

Действительно какая-то пьянка вокруг массива и указателя. Не вижу принципиальной разницы как получать доступ к элементам памяти - через [] или через *(). Если присутствует многомерность памяти, определяю указатель на тип строки такого массива и также адресую - либо индексно, либо *().
Кстати, при объявлении массива можно полностью избавиться от его идентификатора (в C99) и присвоить его адрес указателю.

Не совсем. Верхний индекс принято называть именно superscript.