- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <limits.h>
int gcc_rtm_virt_test(int a, int(*f)(int, int(*)(), float*), float fa[static (-1,0,1)]) {
short s = sizeof (short) + sizeof 0;
char b[12] = "0123456789";
for (long ll = sizeof b; ll -= 4;) {
b[ll] = '0';
b[ll-1] = '1';
b[ll-2] = '2';
b[ll-3] = '3';
}
return s - ((1 << 2) - (b[0] - '2'));
}
int gcc_rtm_cf32(int(*f0)(), int(*f1)()) {
ptrdiff_t d = f1 - f0;
// guess you know what you're doing
if (! (d >> sizeof (ptrdiff_t) * CHAR_BIT - 1)) {
while (d--) {
switch(*(unsigned short*)(f0 + d)) {
case 0xc3c9:
return 0;
case 0xb8:
if (!*(unsigned int*)(f0 + d + 1)) {
return 1;
}
break;
case 0xC031:
return 2;
}
}
return -1;
};
return -2;
}
int main() {
switch (gcc_rtm_cf32(gcc_rtm_virt_test, gcc_rtm_cf32)) {
case -1:
fprintf(stderr, "Hey, added smth. special? Maybe -Og? \n"), abort();
break;
case 0:
fprintf(stderr, "Hey, -O0 smells like a dead rat.. check your flags!\n"), abort();
break;
case 1:
fprintf(stderr, "Hey, -O1 is still not allowed.. Would you do better?\n"), abort();
break;
case 2:
fprintf(stdout, "Hey, finally you've captured [-O2 || -O3 || -Ofast || -Os] flag!");
break;
default:
fprintf(stderr, "Hey, looks like you've got impl. defined crap, check PTRDIFF_T stuff.. \n"), abort();
break;
};
}
И далее по тексту..gcc'шники опять обкурились в рантайме. Зачэм так делоть, это прикольно?
Follow us!
А параметры функции gcc_rtm_virt_test — это вообще издевательство.
> параметры
ага, сидел, пытался распарсить, а они нигде и не используются
Какой багор )))
static в массивах как индексация функциональных параметров появилась в С99 как вариант оптимизации, читай откупа разрабам компиляхторов. C явным "-std=c89" работает в gcc и шланге, в Intel строже - только с С99.
Это если мы только о а-ля x86 ширпотребе говорим..
Что интересно выдаст Texas Instruments например, а, господа микрушники?
Я когда-то носился с криками "А где в VC мои VLA??", ну и мне ответили, что твои VLA в C99, а VC это C90, и если хочется VLA, то иди в C++ (который VC как раз отлично поддерживает) и там тебе выдадут вектора.
Но...
https://en.cppreference.com/w/c/compiler_support/99, «Cvr-qualifiers and static in [] within function declarations» — полагаю, это оно.
PS: Если приспособить к жопе
компилятор фирмы Cray
Это хорошее, годное байтоебство. Такое байтоебство мы уважаем. Один вопрос только: AFAIK СИ обязан представлять отрицательные числа через доп код только с недавних пор, раньше мог иначе предоставлять. Значит ли это, что раньше этот код был бы неверн?
Хотя шансы на иное представление отрицательных чисел примерно как на CHAR_BIT = 8
Сишка гарантирует, что оно не меньше 8.
Восемь бит стали требовать позже (в C99?).
Интересно, было ли в какой-нибудь реализации меньше семи бит.
> дою не кодно
До изобретения BOM
но самый главный посос конечно это cp1251. Вот буквально придумали граблю на пустом местпе
С этого и начался 64-битный бум.
Странно только, что ради этого они символы кириллицы перенесли на новое место. Ведь могли же оставить на досовском.
Если бы в MS оставили кириллицу на старом месте, то при выборе неправильной кодировки пользователь терял бы только кавычки и тире, а не получал бы «хую» вместо «его».
В DOS с 6-й версии и в том, что встроен в 95/98/Me, была команда MODE CONSOLE CODEPAGE PREPARE (сокращённо MODE CON CP PREP), которой можно было загрузить шрифт для полноэкранной консоли. Некоторые почему-то по старой привычке ставили Кейрус (который тоже спас бы).
DISPLAY.sys
https://info.wsisiz.edu.pl/~bse26236/batutil/help/DISPLAYS.HTM
вот он был жырнее кируса
А я его вычистил склорее всего, и потому без кируса нихуя и не работало
А кнопки делал keyb.
Всякие tsr делали и то и другое и были компактнее.
Компактнее в смысле потом с этим жить, 640 килобайт не резиновые.
Отсутствие такой строчки в config.sys приводило к баграм.
Причём прошит был тоненький шрифт ISO, а не жирный, к которому все привыкли.
После перехода на SVGA пришлось снова следить за шрифтами.
В вузе я видел кривые русификаторы, которые загружали шрифт не для всех видеорежимов. Например, 8x16 и 8x14 был, а шрифт 8x8 автор русификатора сделать забыл. Нахуя админы ставили такие русификаторы вместо штатной команды mode? Чтобы один килобайт оперативки сэкономить?
А так я понимаю, для чего нужен Кейрус: у него кроме РУС и ЛАТ была третья раскладка: для рисования рамок и прочей псевдографики. Прикольно же.
В какой-то момент у меня вместо нормального SB оказалась Opti931, а ей нужен был драйвер. И еще сидирому драйваер и mscdex ебучий. И мыши драйвер. И руссификатор. И еще там всякого. И гоблины не влазили, и хуй.
ps: memmaker помниш?
Пришёл к оптимальной конфигурации не сразу. Долго учился. Наконец, сделал так, что досовским программам стало доступно 635 килобайт памяти (ага, типа ДОС и все драйвера уместились в 5 кило).
Ядро доса кинул в UMB, драйвера в UMB и в HMA. Нашёл драйвер мыши, который умел в cloaking (гы!): в V86 что-то перемещал в память защищённого режима.
Самое главное — я отказался от процедуры «optimize» QEMM, которая что-то тестировала и трижды перезагружала компьютер. Она генерировала неоптимальную конфигурацию. Я же узнал про ключик /O, который ищет оптимальное место для драйвера при каждой загрузки и делает это быстрее, чем «optimize». Почему так, не знаю.
Я тогда сорта верхней памяти плохо понимал, разобрался только когда читал Гука:
https://i.postimg.cc/4dX455Bv/image.png
Из UMA вычитай:
— Весь сегмент A000 (64К), если у тебя EGA/VGA/SVGA.
— Полсегмента B800 (32К), если у тебя не MDA (если MDA, то полсегмента B000).
— Выше C000 небольшие сегменты сожрут видеокарта и SCSI- и RAID-адаптеры (если есть).
— E000 сожрёт окно EMS в память реального режима.
Итого от UMA остаётся: 32К в B000, если у тебя не MDA; несколько кило в C000, если из 64К вычесть видеобиос (и другие внешние биосы); гарантированно 64К в D000.
Негусто. Хорошо, что ДОС был маленьким.
QEMM позволял в стелс-режиме выжать больше, но я не включал этот режим, поскольку считал опасным (там использовалась технология теневых блоков, и QEMM, чтобы решить, куда адресовать, к планке памяти или к другому железу, выяснял, кто запрашивает эту память).
Какое AWE )))
Ну а потом Лотус-Интел-Микрософт решили, а почему бы не смумулировать программно эту хрень, ведь теперь на борту оперативки много, а DOS её не видит.
Ценой чисто программной мумуляции стал перевод процессора в режим V86, иначе как-то тяжело маппить.
А XMS работает по-другому, у него нету окна, вместо него API для copy-paste оттудова сюда и обратно. На момент копирования (если сейчас не V86) он переключается в защищённый режим, а потом обратно.
Отцы ебалися PAE, AWE
А нам досталися x64 и похуй пляшем
PAE и AWE — в каком-то очень серьёзном ПО использовались.
У 32-битного Watcom C помимо модели памяти Flat была ещё сегментная модель. Где реально использовалось, не знаю, но возможно, что как раз ради доступа к объёму сверх четырёх гигов.
Сам user mode софт, как ты понимаешь, мог быть и unaware, потому что это чисто заморочка менеджера виртуальной памяти. Причем это умели кажется только серверные винды.
А вот AWE было разве что в MS-SQL (может, в Exchange еще) потому что кому нахуй нужно хранить в памяти более четырех гигов?
Это вообще очень дохуя же. Было. В 2001-м году. Да.
Про 3 гига и PAE помню. В Винде ещё надо было патчить ntoskrnl, если у тебя нет лицензии Ultimate или Premium. В лоховских лицензиях эта функция была заблокирована.
Угадайте, какой максимальный размер массива в ЯЖА?
В Яже размер массива измеряется в int*. Никаких тебе size_t и иже с ними. И конечно всё знаковое (беззнаковых типов в ЯЖА нет).
Мозги яжа программиста очень слабые, и чтобы их не повредить случайно, его избавили от всякой сложной программерской питушни.
*4 байта всегда на любой арзитектуре
Беззнаковых тоже нету, но у массива могут быть отрицательные индексы, поскольку это и не массив вовсе, а ассоциативный массив.
Но вот реализация JVM и компилятора...
Джава растет их Ынтерпрайза, а там обычно стат типизация.
Скриптушня растет от волосатых юникс-хакеров.
PHP это какой-то просто случайный экивок истории случился: в Perl ротоебов нет
ЗЫ: джава язык очень тупой. Там всё влоб, и ничего нельзя. Любую задачувсегда можно решить достатиочным количеством бойлерплейта.
В лицо впиваются снежины.
До остановы добегу ли,
В снегу не утопив ботины?
А дома ждёт меня тарела,
Тарела гречи с белой булой;
В ногах — резиновая грела,
И тапы мягкие под стулом.
В железной бане — две селёды,
Торчат оттуда ложа с вилой.
Есть рюма и бутыла с водой,
Она обед мой завершила.
Я в кружу положу завары,
Раскрою «Кобзаря» Шевчены —
Поэта уровня Петрары
И Валентины Матвиены.
сложность вашего алгроритма -- O(3,14)
А сколько в вутекоде?
Твое решение для случаев i < 3G действительно чуть медленее, чем одномерный массив, но поскольку оно всегда одинаковое -- это O(1).
Другой вопрос, что оно не вмещает данных больше чем 4GB * 4GB, так что через через семьдесят его всё равно придется переписать на трёхмерный массив.
ЗЫ: оно напоминало мне как в MMU плодили уровни страничных таблиц с ровно с такой же целью
А еще можно заказать жырные страницы если у тебя памяти дохуя.
зы: ебаныестраницы убили сегменты: целый пласт культуры ушел псу под хвост
Так вот 2*pow(n, 0) и 1*pow(n, 0) — это всё O(1), только A разное.
правда? А если он указывает на элемент в районе 64 гигабайта?
Трудно было писать мышиный кот под «Спектрумы» и под «Apple-II».
по линии библиотекаря
Я: ыыы, я знаю чем XMS отличается от EMS, и как подключали HDD к PC XT в 1986-м году, ыыыы
Какая ELIZA )))
Винда использует UTF-16. Если текст без иероглифов и без смайликов (которые используют пары суррогатов), количество символов считается мгновенно.
В UTF-32 вообще всё мгновенно считалось бы, но она слишком прожорлива: типичный текст без китайщины будет содержать много нулей.
У тракториста?
f это указатель на функцию, которая возвращает int. А получает она в качестве аргумента int и указатель на функцию, которая возвращает инт, а еще указатель на флоат
Зачем проверять флаги компилятора таким поехавшим способом в уже скомпилированной программе?
0xc3c9 — это LEAVE; RETN;
0xb8 — это MOV RAX, константа;
0xc031 — это XOR RAX, RAX.
На других процессорах не сработает. Да и в компиляторе с другим кодогенератором, который не генерирует LEAVE (он ведь может сделать MOV RSP, RBP вместо LEAVE или вообще опустить «стекфрейм») или использует другие регистры, тоже.
Аффтар видать знатно раскурился: неплохой уан лайнер-выебоша !*(unsigned int*)(f0 + d + 1) ->> mov eax, 0 >> b8 00 00 00 00
Или это нужно чтобы не таскать базу компиляторов за собой?
-frecord-gcc-switches
Возможно, чтобы не таскать базу. Или для тяжёлых случаев вроде нового компилятора, которого нету в твоей базе.
Это всё реалии 1989-го года такие.
В 2025-м твоя програ компилируется скорее всего под три компилятора: clang, gcc и vc. И это еще тебе повезло, если под все три. Если ты пишешь на плюсах, то надо знать еще версию, потому что стандарт быстро менячется.
Не только. Еще потому, что в разных версиях компилятора разные баги, и поэтому в зависимости от версии надо юзать или не юзать какие-то костыли для их обхода. Версия стандарта при этом та же
https://github.com/hanickadot/compile-time-regular-expressions/blob/aa31a2537e6563c1792e9bef0fe2be7122c4a8ee/include/ctre/functions.hpp#L34 например
>I found that a type deduction placeholder in class nontype template parameter is not resolved properly if given as template argument to a class.
>
>GCC 9 HEAD (commit: 20f6624). Example attached with marked problem. Also found workaround using function template with a class nontype template parameter.
Именно поэтому я за Си. Там нет никаких "type deduction placeholder in class nontype template parameter"
зачастую ближе к ху*, когда нужна компактность - предпочтительнее проверка в runtime.
Справедливо не только для devtooling аля сборка, быдлокододегенерация, тесты, но и вполне промышленных, прости Господи, решений
Оставьте все в покое несчастный BP уже. Вам регистров мало что-ли на x64? Или вы хотите чтобы без символов вас невозможно было стектрейсы разбирать?
В -O0 куча попов вместо leave, в -O1 реальные вычисления вместо mov eax, 0. Т. е. оптимизатор ломается.
С -march=i486 такая же ерунда, как с i386, но появляется ebp.
Только -O2 и более сильные оптимизации выдают неизменный выхлоп xor eax, eax.
Почему же gcc обосрался? У них отдельный оптимизатор для этих архитектур вместо тюнинга основного оптимизатора?
Почему же в gcc этим занимается кодогенератор?
Это значит он появился в AT (двойка), но в 5150 его не было.
Имхо:
Потому что в 8088 всем было похуй на языки выского уровня. Весь серьезный софт писался на асемблере, и передавал параметры через регистры.
Пуша и Попа тогда же поримерно появились
Хотя впринципе похуй конечно как он передавался, важно ято функции нужно было место под локалки, но может у тебя и локалки не локальными были
F0 0F и FDIV — капля в море по сравнению с тем, что успел натворить Интел за свою историю.
И вообще, если прямо так хочется, можно настрелять выхлопов кодогенератора и сравнивать с содержимым памяти *main
Спасибо, что без Duff's Device сегодня.
Дело в том, что doomginho (более известный как Уёбок, или Доктор Смегма) не разбирается в программировании. Он, по правде говоря, ни в чем не разбирается кроме педофелии и гомосексуализма, и потому комментирует случайные посты случайнами фразами.
Отвечать ему тут считается тут дурной приметой, и он у всех в игноре.
В данном случае он не спрашивал вас "почему не Duff?", он просто не знает, как switch в C работает.
https://govnokod.xyz/_28093/#comment-804730
по количеству ненужного кода пыхер уделывает джависта
сука, что в 2002-м, что в 2025-м: кал себе не изменяет
сука
https://pbs.twimg.com/media/GoajpbEXEAAHEdp?format=jpg&name=medium