максимальное число элементов в массиве в С?

И как это относится к тому что спросил я?

Т.е. ты хочешь скахать, что если я напишу такой код:

int *c=(int *)malloc(1); c[1];

Да ты сам матчасти не знаешь

Что отличается p1 от p2?

#include <stdio.h>
int main()
{
    char m[1];
    char * p1 = m;
    char * p2 = &m;
    printf("%p\n%p\n",p1,p2);
    return 0;
}

0x7fff815a51ef 0x7fff815a51ef

Они одинаковы.

[] - обёртка над адресной арифметикой

А что кто-то говорил про оператор []?

скобочная нотация это синтаксический сахар над арифметикой указателей и операцией разыменования

Да идёт, я в соседнем топике писал об этом. Это даже будет валидно для маллока(гнутого), а не относительно маллока - это будет валидно всегда.

Ну расскажи мне что-нибудь про матчасть, авось низнаю.

А теперь бери -S в зубы и пойми, почему ты балабол.

Ты хоть сам понял что сказал? При чем здесь скобочный синтаксис? Я про доступные смещения для участка памяти заданного размера. Не нравится

c[1]

*(c+1)

Ткни в тот топик, где ты это обосновывал. Почему ты думаешь, что не выйдешь за границу страницы памяти и твоя программа не свалиться в сегфолт? Конечно, я не утверждаю, что будет сегфолт в том коде, но допускаю, что при некоторых обстаятельствах ты на него нарвешся. При каких, зависит от конкретной реализации malloc и связанных функций.

Да идёт

Что идет, куда идет? Я не о том, что данный код не будет работать, я о том, что его работа не гарантируется.

        leaq    -17(%rbp), %rax
        movq    %rax, -8(%rbp)
        leaq    -17(%rbp), %rax
        movq    %rax, -16(%rbp)

Как видишь код генерирует одинаковый.

Разупорину етому чяту за счет заведения !

Т.е. это гвоорит о том, что я прав. Сравнивать &m и m не имеет смысла, ибо &m для m не работает. И о5 ты поделил на ноль. Мне лень с тобой бесконечно болать, я ответил на все твои более-менее вменяемые вопросы жду ответов.

Пока ты несёшь херню и мне это не нравится.

Что значит не работает? Значение имеет? Имеет. Если ты не понимаешь откуда оно берется, то это лишь твои проблемы.

жду ответов

Эм... На что ответы ты ждешь? Где вопросы?

:)

т.е если вся память адреса 0...2^64-1 то массив элементов единичного размера начинающийся с 0 адресса не может в себе содержать элемент максимального значения типа индекса

да. Потому-что на самом деле это указатель плюс сумма ptrdiff_t. Последний как раз и имеет размер достаточный для адресации всего адресного пространства.

Потому-что на самом деле это указатель плюс сумма ptrdiff_t.

это частность

по факту это фундаментально если количественное той же длины битности что счётные и счётные начинаются не с 1.

по факту это фундаментально если количественное той же длины битности что счётные и счётные начинаются не с 1.

пофиг с чего они начинаются, ибо при объявлении массива там может быть ТОЛЬКО константное целое, которое может быть ЛЮБЫМ. Хоть 100500100500. Компилятору глубоко нас рать, он именно столько и выделит. Вот

00000000004005e8 <main>:
  4005e8:       55                      push   rbp
  4005e9:       48 89 e5                mov    rbp,rsp
  4005ec:       49 bb 00 00 00 00 a2    movabs r11,0xffffffa200000000
  4005f3:       ff ff ff 
  4005f6:       4c 01 dc                add    rsp,r11
  4005f9:       b8 00 00 00 00          mov    eax,0x0
  4005fe:       c9                      leave  
  4005ff:       c3                      ret    

Эх... Еще один.

Вот у тебя есть элементы a[0], a[1], ..., a[PTRDIFF_MAX], где PTRDIFF_MAX — максимальное число, которое может хранить тип ptrdiff_t. Сколько всего элементов? Может ли вместить объект типа ptrdiff_t число равное количеству этих элементов.

s/этих элементов./этих элементов?/

Вот у тебя есть элементы a[0], a[1], ..., a[PTRDIFF_MAX], где PTRDIFF_MAX — максимальное число, которое может хранить тип ptrdiff_t. Сколько всего элементов? Может ли вместить объект типа ptrdiff_t число равное количеству этих элементов.

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

Какая разница-то?

при объявлении массива там может быть ТОЛЬКО константное целое

Как минимум с C 99-го года это не так.

которое может быть ЛЮБЫМ

А это вообще ерунда.

$ cat ardecl.c  
#include <stddef.h>
#include <stdio.h>
int main()
{
        struct { char f[0x10000000000000000ULL]; } s;
        s.f[0xffffffffffffffffULL]=1;
        size_t x=sizeof(s);
        printf(«%zu\t%zu\n»,x, sizeof(0x10000000000000000ULL));
        return 0;
}
$ gcc ardecl.c  
ardecl.c: In function ‘main’:
ardecl.c:5:18: warning: integer constant is too large for its type [enabled by default]
ardecl.c:8:32: warning: integer constant is too large for its type [enabled by default]
$ ./a.out
0       8

при инициализации там просто целое число

Где там?

Ты на вопросы хотябы думаешь отвечать? Или просто поболтать вылез?

Ах, да. Присваивание тут лишнее и оборачивание массива в структуру тоже — это можно игнорировать, суть не в этом.

Как минимум с C 99-го года это не так.

это отдельный случай. Я не знаю как оно там будет.

warning: integer constant is too large for its type [enabled by default]

что хотел-то? Нет у тебя таких целых типа ULL. Иди реквестируй ULLL для 128и бит. ИМХО пора.

при инициализации там просто целое число

Где там?

в инициализации. Где же ещё?

Ты на вопросы хотябы думаешь отвечать?

объясните тормозу суть спора.

Ты не понимаешь. Если будет ULLL, то я не буду использовать число 1ULLL<<64, я буду использовать 1ULLL<<128 (вернее не его, но, я надеюсь, идею ты уловил).

идею уловил, но суть спора не понял. Ну вылезет у тебя твой 1<<128, что дальше-то? Ты намекаешь на то, что в C нельзя сделать целые константы любого размера, больше самого большого типа? Нельзя. Дальше-то что?

Суть в вопросе: будет ли массив, количество элементов которого задается числом, помещающемся в объект некоторого целого типа (назовем этот тип T), содержать элемент с идексом, равным максимальному значению типа T?

Дальше-то что?

Ничего. То о чем начал говорить ТС уже объяснено в топике. ТС согласился с тривиальностью вопроса. Дальше топик представляет собой, по большому счету, сплошной срач.

что хотел-то?

Хотел показать, что ты, говоря «при объявлении массива там может быть ... целое, которое может быть ЛЮБЫМ», был не прав. Как понимаешь, ЛЮБЫМ оно быть не может.

Суть в вопросе: будет ли массив, количество элементов которого задается числом, помещающемся в объект некоторого целого типа (назовем этот тип T), содержать элемент с идексом, равным максимальному значению типа T?

почему нет? Массив заданный числом int 2147483647 (INT_MAX на сегодня для x86 и x86_64) будет содержать эл-т №2147483647. Не вижу проблемы и повода для спора.

Хотел показать, что ты, говоря «при объявлении массива там может быть ... целое, которое может быть ЛЮБЫМ», был не прав. Как понимаешь, ЛЮБЫМ оно быть не может.

любым неотрицательным не более MAX, определённого в limits.h

на сегодня

#   define ULLONG_MAX	18446744073709551615ULL

Ну а число эл-тов не может быть равным индексу, ибо индексы отсчитываются от нуля(это же смещение), а число элементов меньше 1 не имеет смысла. Это ещё Екклесиаст Over9000 лет назад знал.

число эл-тов не может быть равным индексу

Где я говорил про равенство числа элементов индексу? Я говорил про принадлежность этих значений одному типу.

А массив «заданный числом» 4 содержит элемент с индексом 4? Или только 4-ре элемента с индексами 0, 1, 2 и 3?

Где я говорил про равенство числа элементов индексу? Я говорил про принадлежность этих значений одному типу.

а! т.е. вы спорите о том, что размер и координата — разные вещи, хотя и то и другое измеряется рулеткой, ИЧСХ в метрах?

А массив «заданный числом» 4 содержит элемент с индексом 4? Или только 4-ре элемента с индексами 0, 1, 2 и 3?

бревно распиленное на 4 части состоит из четырёх чурбанов. Если бревно только что распилили, и чурбаны никто не трогал, то первый чурбан лежит на расстоянии 0см, второй N*1 см, третий на расстоянии N*2см и т.д. Если все чурбаны одинаковы и размер любого N см.

И какой чурбан этого здесь не понимает?

бревно распиленное на 4 части состоит из четырёх чурбанов. Если бревно только что распилили, и чурбаны никто не трогал, то первый чурбан лежит на расстоянии 0см, второй N*1 см, третий на расстоянии N*2см и т.д. Если все чурбаны одинаковы и размер любого N см.

третий на расстоянии N*2см и т.д.

Не и т.д., а четвертый на расстоянии N*3см. А на расстоянии N*4см нет чурбана (4-ый уже закончился), так как у нас нет 5-го чурбана.

И какой чурбан этого здесь не понимает?

Ну, судя по этому твоему сообщению «Массив заданный числом int 2147483647 ... будет содержать эл-т №2147483647» — ты.

размер и координата — разные вещи, хотя и то и другое измеряется рулеткой, ИЧСХ в метрах

Ну, можно и так сказать, хотя я не люблю аналогий.

вы спорите о том[/quote Где мы об этом спорим?

А на расстоянии N*4см нет чурбана

да.

Ну, судя по этому твоему сообщению «Массив заданный числом int 2147483647 ... будет содержать эл-т №2147483647» — ты.

нет. четвёртый чурбан есть. А тут есть 2147483647й элемент. У него индекс 2147483646, а №2147483647.

№ == «порядковый номер». Это НЕ индекс. Ибо я уже устал вам объяснять, что ИНДЕКС это РАССТОЯНИЕ. Это вообще ДРУГАЯ хрень. У неё даже тип в сишечке специальный, НЕ int, а ptrdiff_t.

№ == «порядковый номер»

А! Ну тогда, прости, погорячился.

НЕ int, а ptrdiff_t

ptrdiff_t — это typedef какого-то знакового целочисленного типа. О том что он не int я бы говорить не рискнул.

размер и координата — разные вещи, хотя и то и другое измеряется рулеткой, ИЧСХ в метрах

Ну, можно и так сказать, хотя я не люблю аналогий.

это НЕ аналогия. Число байтов(чурбанов, чего угодно) это одно, а расстояние от… (индекс) это ДРУГОЕ. И это несмотря на то, что измеряется в одном и том же. Строго говоря, индекс — это путь. Он может быть и многомерным, к примеру состоять из набора битов (влево/вправо), как в дереве. Такие индексы не аддитивны вовсе, хотя тоже выражаются целым числом из обычных битов. Т.е. вычитая два таких индекса, мы НЕ получаем расстояния. Вычитание у нас неправильное. Возможен также индекс над Nмерным гиперкубом. Расстояние между двумя такими индексами считается не вычитанием, а сложением. По модулю два, а потом суммированием единичек.К примеру из вершины 010 нужно как минимум три хода в вершину 101. Можешь сам попробовать на обычном трёхмерном кубе(ходить можно только по рёбрам).

Т.е. индекс однозначно определяет эл-т, но множество индексов вовсе не обязано хоть как-то ложится на множество номеров. Массив в паскале — единственное исключение, которое только сбивает с толку неопытных кодеров.

ptrdiff_t — это typedef какого-то знакового целочисленного типа. О том что он не int я бы говорить не рискнул.

а я говорю. И я в этом _уверен_.

Это НЕ int, а кто считает это int'ом — тот ламо и быдлокодер. Хотя конечно оно _может_ быть int'ом.

К примеру из вершины 010 нужно как минимум три хода в вершину 101.

блин, 5-2==3. Плохой пример. Пусть будет 110 ←→ 001 == 3 (хотя 6-1==5)

Т.е. вычитая два таких индекса, мы НЕ получаем расстояния

Не говори ерунды. Хотя, стоп. О каком расстоянии идет речь?

оно _может_ быть int'ом

О чем я и говорю: нельзя утверждать что ptrdiff_t не int.

Если ты вводишь трехмерный индекс, зачем пытаешься его перевести в одно число? Твое «расстояние» будет вычисляться как

|1-0|+|1-0|+|0-1|

это НЕ аналогия

Тогда мы о другом говорили: нет у нас ни метров, ни рулетки.

Т.е. вычитая два таких индекса, мы НЕ получаем расстояния

Не говори ерунды. Хотя, стоп. О каком расстоянии идет речь?

о том самом. Индекс — путь. Т.е. вектор перемещения. Запись a[-17] говорит нам о том, что надо идти от базы на 17 эл-тов влево. Просто инициализация _отличается_ от индексации, несмотря на то, что в сишечке это с виду одно и тоже. Выражение в [скобках] имеет РАЗНЫЙ смысл. В сишечных массивах индекс аддитивный, т.е. допускает сложение и вычитание. a[10+20] эквивалентно a[30]. Но это частный случай на самом деле.

Т.е. смысл выражения [в скобках] РАЗНЫЙ, и тип тоже разный. ОДЗ тоже разная. И нет ничего странного в том, что номер элемента не совпадает с расстоянием(точнее с путём) эл-та от базы.