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

Именно так адрес-константа созданная компилятором для хранения указателя на массив abc[]. Соответственно будет использоваться компилятором, когда потребуется указатель на массив abc[].

Потрудился показать, что для работы с массивом abc[] компилятор выделяет память для указателя abc. Если с массивом НЕ работать, память под указатель выделяться не будет, но и сам массив будет выкинут при оптимизации по причине его нахренненужности.

Вижу еще одного страуса. Интересно, а где еще GetSmart .

Ну и где там написано, что адрес констаты нельзя получить? Там написано только то, что значение, связанное с идентификатором константы, обычно нельзя изменить. В фортране так и без никаких «circumvent»-ов, просто по неосторожности.
Если речь идёт о С, то изобретательность проявили Вы -- в стандарте С «константами» называются только числа, идентификаторы enum и символьные литералы. Имя массива в нём константой не называется. Даже строковые литералы не называются «константами».
А у «константного объекта» адрес может и браться, в зависимости от.

Но я не об этом, не о «взятии адреса константы».

Несмотря на Вашу уверенность как в том, что abc есть константа, так и в том, что адрес константы получить нельзя
&abc вполне себе возвращает адрес, только не константы, а массива. Не первого элемента массива, а всего массива.
По одной причине -- имя массива не есть «константный указатель». Имя массива -- выражение, означающее «массив элементов такого-то типа». К выражению «указатель на объект такого-то типа» со значением адреса первого элемента массива оно только автоматически приводится, но не всегда. Одно из мест -- как раз обсуждаемый унарный &.
Другое -- sizeof(abc), который возвращает размер не «указателя-константы которая равна адресу первого элемента массива с нулевым индексом», а массива.
И строковый литерал "foo" в контексте инициализации символьного массива ведёт себя не как «константный указатель на первый элемент» строки (неявного массива символов). И, кстати, &"foo" допустимо на тех же правах, что и &abc.

Так что почитайте книги, если считаете что Вам, в отличие от меня, они ещё помогут.

____________________________
-- Множество чего?
-- Просто множество.

Уважаемый, не тупите, и почитайте(внимательно) всё написанное выше, ведь из за Вас всё это бодание началось.

1. Если нужен глобальный, то объявляйте максимально возможного размера и не парьтесь.

Максимально возможного размера это такого размера, который допускает компилятор+линкер, т.е. вся доступная свободная память.

2. Это будет самый простой и надёжный вариант.

Ой ли.

3. Он гарантирует, что памяти хватит на самый большой шрифт, и при этом не использует динамического распределения памяти.

Ничего этот максимальный размер не гарантирует.

4. Ведь вам в любом случае нужно иметь память под самый большой шрифт, пусть она сразу и будет выделена.

Эта фраза входит в полное противоречие с пп.1-3. На самом деле, максимального возможного размера надо интерпретировать, как минимально необходимого для копирования максимально широкого символа максимального большого шрифта используемого в настоящий момент в программе.

Учитесь, мой друг, свои мысли однозначно излагать, а не считать всех старыми козлами. Я ваш текст читаю, а не шарады разгадываю на тему, что вы там имели в виду.

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

А следуя вашей замечательной логике основанной на кривой реализации, компилятор и под каждую функцию будет размещать слово, в котором будет лежать ее адрес.

Уверен, что вы и сами прекрасно понимаете что были неправы, а теперь пытаетесь свернуть разговор на другие рельсы и оправдаться совершенно нелепыми ссылками на "а вот у кейла так сделано". Да они могут перед каждым массивом и слово для хранения размера резервировать - а вот захотелось так, для тестирования или еще и что вы тогда скажете, так в языке задумано?


На эту фразу хотелось бы обратить особое внимание. Оказывается ваше невежество глубже чем казалось. Вы что, считаете что компилятор генерирует слово с адресом вообще всего? написали &IntVar - ну какже, адрес переменной же не может взяться из ниоткуда, значит, под него слово будет зарезервировано, и туда написан адрес этой переменной. Адрес, взятый из ниоткуда. Вы вообще знаете для чего линкер существует?

Остается надеяться, что этот бред вы написали хорошо расслабившись после тяжелой трудовой недели - другого объяснения я не вижу

Наверное-таки, не константа, а литерал. У константы может быть адрес (константа - неизменяемый объект).

По общему смыслу полностью согласен - у литерала нет адреса. Но у массива (как целостного объекта) адрес, конечно, есть.

Странно, но большинство видимо стандарты не признают
ISO/IEC 9899




Глупости тут пишите только вы, хакир-орнитолог вы наш. Не создается никаких указателей при определении массивов - неужели не понятно ? Этот указатель - внутренний изврат компилятора.

Я здесь. Отошёл поспать.

Хорошая ветка. Давно так не веселился. Мне добавить нечего

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

Пожалуй добавлю кой-чего.



Я в начале ветки просил обратить внимание на другие объекты Си - на структуры и юнионы. Применение амперсанда ко всем объектам в языке Си должно быть логически одинаковым. Кроме того, при сравнении использования структур, юнионов и массивов проявляется, как уже многие подчёркивали, искусственность подмены идентификатора массива в указатель на его первый элемент. Это видно при применении индексации к любому типизированному указателю. В структурах и юнионах не так. Там есть два разных вида доступа к полям - из самого объекта и из указателя на объект. И нет автоматической подмены указателя и объекта. Так вот, если есть юнион abc и выражение p = &abc, то было бы совсем непоследовательно со стороны разработчиков, если они для юнионов и структур брали бы при этом указатель на объект, а для массивов (ввиду их избирательной автоматической подмены) сделали бы взятие указателя на указатель на массив, который ещё и разместить где-то надо, и точно не в ROM-e. Амперсанд функций и простых переменных так же показывает целостность картины использования амперсанда - есть объект и, если перед ним стоит амперсанд, то будет взят адрес объекта с типом самого объекта. При этом автоматическая подмена объекта/идентификатора массива (и только массива) в указатель на первый его элемент сыграла злую шутку с программистами со старой "прошивкой"

Ну ладно, если вам так жить удобнее, постановим, что вы умнейший умница, а я глупейший глупец. Простим друг друга и пойдем отдыхать.

Зачем надо было писать так много глупых слов? Вы себе даже не представляете, как "легко" и просто Вы можете посрамить одним махом и меня и писателей кривых компиляторов . Для этого просто надо написать эти несколько строк на Ассемблере "правильно", так, что-бы абсолютный адрес брался не из ячейки памяти а из типа ниоткуда. Жду с нетерпением демонстрации извлечения абсолютного адреса объекта не так, "как это криво сделали они" - взяв этот 32bit указатель из 32bit ячейки памяти, а каким-то неведомым "им" и мне способом.

Нет, не надейтесь, ни в каких языках это не задумано. Для этого я Вам выше предложил выполнить необходимое действие прямо на Ассемблере, или, если Вы считаете, что Ассемблер тоже связывает полет Вашей фантазии, то в машинных кодах. Жду.

Не надо приписывать другим свои невежественные мысли и трактовки. Никогда не говорил, и не мог говорить что компилятор выполняет работу линкера. Каждый делает свою работу.

Вы начинаете бить рекорды человеческой глупости и самоуверенности



И Вас тоже приглашаю дать так сказать мастер класс извращенным писателям компиляторов ну и, конечно мне , и присоединится
к ar__systems в написании нескольких восхитительно прямых команд. Жду.

Интересно -- кто-то еще будет на этом форуме слушать ваши советы после такой конкретной тупизны которую вы тут упорно выставляете на показ ? У вас все смешалось в голове, начинаете доказывать что-то про язык С основываясь листингом ассемблерного кода какого-то говнокомпилятора а то что существуют стандарты - это для вас не показатель. Так вот я еще раз предлагаю привести пример чтобы после объявления массива вы смогли бы оперировать его имнем как указателем (естествеено в С - не ассембере и не перфокарте) - ведь по вашему это указатель и он создается и по вашему стандарту обязан быть.

Вы похоже совсем э...., ибо все происходит с точностью до НАОБОРОТ. На Ваши личные завихрения мне наплевать,но мимо того,что Вы походя продолжаете дезинформировать всех читающих я пройти не могу. В выражении int *ptr = &Buffer как раз и НЕ производится "автоматическая подмена объекта/идентификатора массива (и только массива) в указатель на первый его элемент". Не имеет права нормально написанным компилятором производится. Ругань компиляторов на действия "программиста" ожидающего такую замену я приводил. Ругается естественно на то, что указателю на int не может быть присвоен указатель на массив. Пустой треп за то, что числа-то одинаковые и все и так могло быть хорошо а так-же обвинения языка C в небрежении с типами это Ваш пустой треп . Выражения явно берущие адрес первого элемента массива int *ptr = &Buffer[0], и выражение int *ptr = Buffer неявно, но документировано по стандарту так-же берущее адрес первого элемента массива совершенно нормальны, и были мной приведены в первом-же посте, как вариант безошибочно-правильного выражения мысли программиста. Посему обо всех Ваших последующих выкрутасах и говорить-то нечего.

Зачем опять эти нелепые, пустые и пафосные фразы, когда все можно развеять в пух и прах одним примером?

Все еще хуже - любой язык

Все еще хуже - абсолютно любого компилятора . И не только компилятора,но и ассемблера

Зачем еще раз мне приводить? Он приведен. Один страус сказал, что это "лишняя переменная", Второй страус сказал, что это, "Апельсино-Паровоз".
Оба страуса сошлись во мнении (а действительно, что еще делать страусам, когда они видят "необъяснимое" явление), что это все проделки "говнокомпилятора" - его дяди не просили этого делать, а он взял и разместил в памяти указатель на массив. Больше страусов на данный момент не объявилось.

Хватит уже сопли жевать.
Одного слова Ужас и "бессмысленности" было достаточно для понимания того, что у Вас в голове творится.


Я именно и говорил, что не производится и не должна, т.к. потеряется логика работы амперсанда. Но то, что не будь контроля типов указателей, у ТС всё бы заработало чудесно. Как он говорит, у него так и заработало в Кейле. Мелкая ошибка, даже не ужас vs УЖАС УЖАС УЖАС!

Учитесь правильно оценивать величину ошибок. Может тогда научитесь адекватно воспринимать свои гораздо более серьёзные ошибки

Это не пример ниразу, поэтому я прошу привести пример на _С_ или цитатут из стандарта языка _С_ где говорится что при создании объекта типа массив созается указатель с которым можно далее работать как с указателем - не как с адресом-константой а как с указателем - взять его адрес, изменить значение в соответствии с типом.

Щас доспоритесь до того, что придётся в стандарт вводить допустимость такого


Причём компилятору придётся автоматически решить где размещать объект - в стеке, в раме или в роме. В зависимости от того, к какому типу указателя идёт присвоение.

А Вы не высасывайте из СВОЕГО пальца слова и не приписывайте их мне. Начните, с цитирования того того места, где я, яко-бы утверждаю, что "при создании объекта типа массив созается указатель с которым можно далее работать как с указателем - не как с адресом-константой а как с указателем - взять его адрес, изменить значение в соответствии с типом."
Жду, а то страусы сотворили для себя глупость и с упоением воют

Как же быть если вы отвечаете на мои слова
http://electronix.ru/forum/index.php?showt...st&p=949780

кому и чего я приписываю если вы утверждаете что создается указатель, я говорю что указатель не создается. Что непонятно ?
А вот с чего началось - товарищ сделал совершенно неправильное заявление, на что я и возразил
http://electronix.ru/forum/index.php?showt...st&p=949672
на что вы начали умничать с ассемблером и гнать жуткую пургу.

Ну так нельзя, вот так (почти так же) уже давно можно:
(«почти» ввиду разницы времени жизни, статическому указателю так не присвоить)
Почему нельзя для скаляров делать то, что можно для агрегатов -- непонятно.

ИМХО, тему пора закрывать, поскольку она сильно вышла из «берегов» а Т.С. давно получил, что хотел .

Указатель создается. Теперь поговорим какой. Тут я думаю, Вам следует почитать первоисточники, благо Вы теперь знаете где их брать
Даю намек, что указатели в языке 'C' предусмотрены стандартом разные,
int *ptr
const int *ptr
int * const ptr
const int * const ptr
Это все, подчеркиваю, все называются указателями. Нет в требований, того, что-бы указатель, если использовать придуманый Вами термин не являлись
"адресом-константой". И так, совершенно очевидно создается константный указатель. После чего я этот факт явно подтвердил в ответ на Ваш вопрос "Именно так адрес-константа созданная компилятором для хранения указателя на массив abc[]. Соответственно будет использоваться компилятором, когда потребуется указатель на массив abc[]"
Теперь когда этот указатель создается. Ни в посте на котороый Вы ссылаетесь, ни в каких либо других я не утверждал, что
этот указатель создается при создании объекта, как Вы мне еще и это пытаетесь походя приписать .
По этому поводу даже есть мое проигнорированное разъяснение, что этот указатель создается для/при необходимости работы с массивом. Вот цитата из поста с тем самым примером:

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

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

Я уже не жду.

Мда. zltigo вернулся.
Предгалаю переименовать тему в "Рандеву с zltigo". Традиционнее, и более соответствовать будет.

Я оставил то, что совсем не то, о чём я написал. Это копирование объекта/структуры. Тут же спор об автоматическом создании объекта, на который постоянно (или хоть локально внутри функции) существует/актуален указатель. Копирование - не есть передача указателя на всеобщее юзание. Из-за этого много интересных моментов не проявляется. Например, константой было число 115 или переменной. Если константой, то указатель должен был быть не int *p, а const int *p.

А вот остальное, убранное, в принципе похоже. Однако, как поведёт себя компилятор, когда функция будет объявлена например так:

Догадается ли он поместить структуру в ROM, применительно к ARM-ам? Или если для других платформ, то const заменить на другой атрибут, например __flash.

Что поделаешь, если есть форумчане движимые в основном целью, которую максимально четко и откровенно, и за откровенность ему мое уважение! Сфрмулировал novchok:

Вот и имеем достаточно постоянную группу "имеющих желание, но не имеющих возможности".
Кстати, я и тогда и сейчас отвечу:

"...но не имеющих возможности"

Я уже как-то указывал zltigo на ошибку в драйвере I2C. Он ответил что-то в духе - я не видел и, типа, у меня всё работает.
Отсюда возникает логичное предположение - писал не он. Хотя заявлял, что он.

Было-бы крайне глупо выкладывать в интернет под своим именем чужое, посему по этому поводу расслабьтесь. Все мое, и ошибки, буде таковые бывали и будут, тоже мои.


Или не ошибке, честно говоря тогда, да и сейчас разбираться в коде написанном на рубеже веков было недосуг. Так и живет, плодится и работает этот код с "ошибкой". Но до чего диагноз данный novichok верен - буквы I2C даже в этой теме GetSmart повторил уже не единожды .

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

Ваш доктор айболит нервно курит в сторонке. И Вы вместе с ним. Оцените суть происходящего, если есть чем. Я ни за кем не гонялся. Нашёл ошибку - один раз сигнализировал. Здесь же на Ваш неадекват по отношению к начинающему (ТС) сначала намекал, что ничего страшного не произошло. Вы же распалились как горящая ёлка. Пришлось ко всему прочему для сравнения и Ваши ошибки выставлять на обзор чтобы в разум привести. А то ведь истерика до сих пор не прошла.


Может быть. Это только предположение. Тогда тем более странен полученный ответ. Мол я выложил, а то, что там ошибка, ну и чёрт с ней. Если я не видел, значит её там нет. Но проверять всё равно не буду.

Автоматически, "на ходу" созданной структуры.
Я для того и написал, чтобы сравнить: в int можно записать 5, в функцию, ожидающую int* -- нельзя передать &5.
А со структурами и массивами -- можно и структуре присвоить не другую заведённую мной ранее структуру, а по-месту сочинённое {1, 2}, и в функцию передать указатель на такой объект.
Впрочем, в С++ под ссылку можно передать константу, при этом, равно как и в С99 с показанными структурой и массивом, заводится (меня не касается где) временный объект, инициализируется даннйо константой (как тут структура инициализируется двумя константами) и передаётся на него указатель.

Да-да-да :-)
Именно с этим у Фортрана и были весёлые танцы. Вызываешь FOO(42), после чего константа 42 изменилась во всей программе (или, по крайней мере, в единице трансляции), так как FOO внутри себя меняет свой аргумент.
Ну уж это можно как-то разрулить, считать константой и не передавать под int *, передавать только под const int *

Да, конечно, я уже слышал , это Апельсин или Паровоз.

Радует уже то, что с указателя втихую сняты обвинения в константности яко-бы неподобающей указателю. Или такти нет? Теперь все это вышенаписанное можно свести к одной "проблеме", что этот указатель, подчеркиваю указатель, а не "Апельсин". Скрыт от программиста. Естественно скрыт, поскольку был создан компилятором а не программистом. Точно так-же компилятор для своих нужд порождает переменные, если они ему нужны, но их не объявил программист. К таким переменным программист так-же не имеет доступа, но это не мешает им быть переменными. Программист может сам явно объявить объект и компилятор им воспользуется. Хотя может и напротив, выкинуть за ненадобностью .



Так со сторонки оно это зачастую очень правильная позиция. В русском языке есть даже такие выражения - "посмотреть со стороны" и "со стороны виднее".

Этот код, как мне помнится, был выложен в ответ на чью-то просьбу в совершенно публичной ветке форума. Вы посчитали, что там яко-бы имеется ошибка. Я по причинам описанным выше вступать в разговоры был-ли мальчик не стал и ответил, так, как ответил.
Все заитересованные лица могли и полагаю, сейчас могут ознакомится с проблемой и составить собственное мнение. Что собственно стряслось, то Вы спустя какое-то количество лет об этом вспоминаете по несколько раз на дню?

Вот как раз идентификаторы функций ведут себя ближе к массивам, чем к переменным. Т.е. идентификатор функции при отсутствии возле него sizeof либо унарного & автоматически приводится к указателю на функцию. Более того, даже тут это делается:

Т.е. идентификатор функции сначала автоматически приводится к указателю на функцию, потом этот указатель скармливается круглым скобкам в роли оператора вызова функции. Аналогично массивам, под sizeof(foo) идентификатор функции не превращается автоматически в указатель на. При этом нарушаются требования для оператора sizeof и имеем ошибку. Однако, в отличие от массива, в выражениях &foo означает в точности то же, что и foo. Посему первые две строки функции moo() полностью равноправны.
А вот с последними двумя строками интересно.

С (3) всё правильно, () по стандарту ждут выражение типа "указатель на функцию" (я уже не раз приводил пример с абсолютно легитимным a = (flag ? sin : cos)(x), где в первых скобках мы имеем как раз выражение типа "указатель на функцию").

А вот в (4)... Такое ощущение, что сначала указатель на функцию в результате разименования превращается в тот самый function designator, который тут же автоматически первращается назад в pointer to function, который уже скармливается скобкам. А тут
это происходит семь раз.

Сразу же хочется заменить функции на массив. И не только. Можно и на структуры и на юнионы.
По логике, должны прокатить конструкции



Называется - доигрались

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

Первая строка не покатит, а всё остальное указатели (для массивов тут, как и в других выражениях кроме двух уже обсосанных, автоматическая конверсия), как и с указателем на функцию -- прекрасно работает. Почему бы указатель на функцию вёл себя иначе остальных...
Как я уже тоже писал -- это ещё в Алголе-68 было, только запись корявее
Жаль, поработать не пришлось. Там много интересного, включая возмжность создать имя для перегруженного созданного для данного типа оператора и задать ему приоритет. Не нужно стандартные слова с прибитыми к ним гвоздями приоритетами и прочими свойстваим перегружать :-)

Но ведь работает :-)

То есть так по идее должно работать?

Нормальный такой пример. Ручками поместили массив и минимальную функцию в общую .text секцию которую разместили в RAM. Соответственно для такого искусственно созданного (поместить в регистр скорретированный программый счетчик)случая необходимости в использовании указателя на объект в .data просто не возникло и он был соптимизирован. Компилятор оказался, как ни странно, вопреки Вашим предыдущим обвинениям не говнокомпилятором и когда ему была представлена ФИЗИЧЕСКАЯ возможность все сделал хорошо.

Доказательство, простите, чего??? Вернитесь к своему посту №80. Перечитайте несколько раз. И объясните хотя-бы себе самому неоднократную отсылку к стандарту языка, который к этому вопросу нималейшего отношения не имеет, поскольку наличие в памяти указателя на массив для работы работы с массивом есть совершенно объективная реальность не нормируемая никакими стандартами. Да и что могло-бы написано в гипотетическом стандарте - "колеса должны быть круглыми"" указатель должен быть", "колеса должны быть квадратными""указателя не должно быть"?

Обязано. Причём со времён K&R-1, в отличие от составных литералов (которые (struct foo){1,2} ), появившихся в стандарте каких-то 12 лет назад.
Об одном братишка стандарт просит, чтобы указатели были одного типа, включая квалификаторы.

То есть результат выражения (или как оно там называется) "?" может быть только скаляр, не арегат, при этом указатель считается скаляром?

А как насчёт вот так

а ещё круче так

Можно даже без скобок, наверное.


Ну это само собой. Не дурак.

А PL/1, у меня, помню, в позднестуденчекие времена натурально от писания на нем ум за разум заходил.

Нельзя, и массивы не присваиваются, и порождўнный из имени массива указатель таки ж константный.

Так можно и всегда было можно. Если можно написать a = b;, то можно написать и a = flag ? b1 : b2;
А вот когда ?: в левой части, то тогда только указатели и только под * либо под ->
Т.е.

заменяется только на


Э-э-э, а вот тут я ошибся.
Сразу усомнился, как только послал сообщение, полез в C89. С типами-то понятно, а квалификаторы могут быть разными, они суммируются.
Т.е. type of ( flag ? pointer_to_const : pointer_to_volatile ) == pointer_to_const_volatile

Вот и получается нестыковка. Результатом выражения "?" в скобках способна быть структура (не указатель на структуру), при этом нельзя от неё брать поле. Хоть структура, хоть юнион.


Опять странно. Массивы не присваиваются, а структуры/юнионы присваиваются.
Тогда может так

Для помощи в решении задачи (не совсем ясно до сих пор какой) прежде всего надо выкинуть из головы лобовые решения типа "хочу массив переменного размера" - я пишу а он растет и растет.
Если уж на то пошло вешайте дополнительную память, поднимайте файловую систему и пользуясь write() пишите, пишите пишите.

Для микроконтролера неимеющего механизмов виртуализации памяти функция маловразумительная .
1)Для начала по любому придется выделить под heap каку-то память.
2)Если этой памятью будет еще кто-то пользоваться, то сколько ее останется неведомо и очень печальный факт в том, что она будет в конце концов фрагментированна.
Максимум, что теоретически можно в realloc для борьбы с фрагментацией реализовать, это находить фрагменты памяти побольше и копировать содержимое . Очень громоздкое и не решающее
проблемы фрагментации решение.
3)Если этой памятью более никто на пользуется, то тогда зачем realloc()
4)RAM на контроллерах всегда маловато, посему если только для решения этой криво поставленной задачи, то заводить heap, отдавать под него память самое плохое решение.
5)Если уж упорствовать и продолжать трясти пальму хотеть переменный массив, то тогда уже выделять его на стеке и ждать чем это все кончится при нехватке глубины стека. В данном случае хоть под стек можно отдать всю оставшуюся память.

Бессмысленно пытаться применять то, что не знаете как устроено и работает реально.

тема называлась так:
Как в си объявить массив с возможностью изменения его размера?

я показал, как это сделать. Про микроконтроллеры ни в теме ни в посте ТС ни слову, так что извините…

P.S. Думаю, ТС нужно создать новую тему, где он четко поставит задачу. Тогда не потребуется 10-ти страниц разговоров, сарказмов и т.п. не относящихся к теме, а мы попробуем ему помочь.

Ну если не считать черным по белому первые слова в первом посте:

Микроконтроллеры сегодня, конечно местами совсем не микро, так-что Вы в чем-то правы. Ну а в общем давайте в советах исходить из того, что Автор, судя по его другим постам,
что-то уровня STM32 (STM32F103VET6) мучает.

Стоп. Сейчас я в этом уже не так уверен. Надо почитать-подумать.
Просто с указателями обычно работа идёт и с ними такие фокусы иногда пишу, становится виднее суть, чем в if. А с цельными объектами такого не делал.
вроде как всегда было можно, значит, и с ?: должно бы.

Это к отцам-основателям... В С массивы не копируются вообще. Не копируются и тут.

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

Самое забавное во всей этой истории, что ТС заварил всю эту кашу и свалил. Видимо переваривать прочитанное (сомневаюсь, скорее пузо греть на солнышке в выходные).

Печально другое. Админы могут, наверное, это выяснить, каков процент постов, который заканчивается словами "Спасибо за ...".

А чего тут думать-то? Трясти надо!

0 errors, 0 warnings. Работает

Для функции &func и func одно и то же абсолютно. Для массива не одно и то же. Можно даже функции вызывать (&func)(params). Со звёздочкой вообще приколы знатные. Я так понял, унарная операция "звёздочка" вынуждает объект определённого типа "автоматически преобразоваться". Амперсанд же не вынуждает, а работает с исходным объектом.
Все эти варианты делают одно и то же


Попробовал. Пока не удалось никак. Видимо это жертва за удобство в другом.

Upd.
Хотя вру. Не всегда одно и то же. Только то, что &func это указатель на функцию с какими-то параметрами. А func преобразуется в большинстве случаев к этому же типу. У массива в первом случае массив, во втором - первый элемент массива.

По логике операции ?: мне не очень понятно. Она может работать с целыми объектами. Но зачем-то вынуждает объект преобразоваться. В то же время простые скобки не вынуждают объект преобразовываться.