xvr

У вас сам массив не константный (добавьте const после static). Но даже это для С может не помочь - там не всё то, что написано с const, является действительно константой :)

https://app.ultralibrarian.com/search?queryText=TORX177 TX нету увы - придётся самому рисовать

Немного занудства - va_list это не массив, а некий псевдо указатель на параметр в вызове функции. Реализация его полностью зависит от архитектуры процессора и иногда от компилятора. Далеко не на всех архитектурах это реальный массив :(

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

Возможно заполняет дырки в пайплайне (обращение в память требуют больше тактов, и если не вставить что нибудь после неё, то процессор просто сам вставит туда nop). Так что влиять на это не стоит - результат будет совсем не таким, какой вы ожидаете

Да. но насколько существенным зависит от процессора Да. как минимум используйте функцию memmove - она оптимизирована для копирования массивов памяти. Если надо ещё быстрее - делайте промежуточный массив указателей на строки - char TERMINAL_TEXT_BUF[256][100]; char* TERMINAL_TEXT[256]; for(i=0;i<256;++i) TERMINAL_TEXT[i] = TERMINAL_TEXT_BUF[i]; Потом копируете указатели в TERMINAL_TEXT (не забудьте их зациклить по исходному массиву - иначе затрёте память)

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

2 ТС: язык С не занимается самостоятельным управлением динамической памятью. Строки (за исключением констант в программе) по своей природе сущности динамические, т.к. могут менять свой размер. Так что у вас 3 выхода: Управлять памятью самому (malloc/free) Выделить сразу массивы достаточного размера, и смериться с потерями памяти, если строки будут короче, и с ограничением на макимальную длинну строк Сменить язык (например на С++ и std::string)

Надо сказать, что программные защиты всевозможных видов, основанные на проверках чего-нибудь, ломаются за считанные минуты :( По собственному опыту (где то 30ти летней давности) - пришлось ломать Автокад. Никаких IDA не было, был примитивный офлайн дизассемблер (не помню уже какой именно) и отладчик (кажется turbo debugger). Защищён он был похоже flex lm (точно не скажу, тогда я таких слов не знал, а сейчас уже концов не найти). На то, что бы найти тот условный джамп и поменять на безусловный ушло пол часа. Потом ломал плагин к нему (Российского производства). Вот там разработчики постарались - там и проверки были, и участки шифрованного кода, и самомодифицирующийся код. В результате всё было сломано за те же 30 минут. Был и опыт с другой стороны. Приблизительно тогда же делал защиту на клон Синклера (ATM-Turbo). Там была встроена CPM (её и защищали) и в качестве аппаратного ключа использовалась ПЛМка (на ней развертка генерилась). Было где то 3 уровня защиты, от простой проверки до трудно уловимых глюков в процессе работы. 2 уровня народные умельцы сломали, о последнем они не догадывались - в результате копии сбоили в работе, а вес шишки сыпались на оригинальных производителей :( Самый цимус этой истории в том, что фирма, производившая эти компьютеры так же производила и программатор (ну и продавала конечно). И одним из примеров в составе программатора были исходники этой самой ключевой ПЛМ (это правда обнаружили когда с производством самих компьютеров уже завязали)

Видимо то, что в реальности они инвентированны (о чём внизу в сноске написано)

Хм, а то, что адреса обоих структур у вас NULL - не смущает?

2 металлических коврика - один до двери, второй после. Подключаем в 220. Пациентов считаем по количеству воплей, при пересечении двери. (Нужен микрофон) PS. Простите, не удержался

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

ТС пытается зашарить между разными процессами 'живые' объекты C#. Наблюдается полное непонимание того, что происходит 'за фасадом' сорцов C# программы. В рамках C# способа нет, инициализируйте из каждого exe. Можно вынести код работы с релюхой в отдельную библиотеку (сборку в терминах C#), что бы не дублировать его многократно. В принципе должно хватить

Код из первого поста - жесть. Откройте для себя, что в string.h есть ещё много других функций, например strpbrk и strcpy И sscanf конечно хорошо, но он очень жирный (много кода за собой тянет). Если у вас нет проблем с размером кода, советую смотреть в сторону регулярных выражений. У вас и есть знаковое (формат %d). Беззнаковое будет %u. А %f - это вообще плавающая точка