LINUX.ORG.RU

Calloc нынче ни на что не влияет что-ли?

 ,


1

5

MWE:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef unsigned char u8;
typedef unsigned int  u32;

#define GB (1024ul * 1024ul * 1024ul)
#define TEST_SIZE (10)

int zerofy = 1;

static u8 * alloc(u32 size)
{
    u8 * res = calloc(size, 1);
    
    if (!res)
    {
        printf(" * Cannot alloc %u bytes\n", size);
        return NULL;
    }
    else
    {
        printf(" * Allocated %u bytes [%p]\n", size, res);
    }

    if (zerofy)
        memset(res, 0, size);

    return res;
}

static void rapemem(u32 zero)
{
    u32 i;
    u8 * p[TEST_SIZE];

    printf("Switching zerofy to %u\n", zero);
    zerofy = zero;

    for (i = 0; i < TEST_SIZE; i++)
        p[i] = alloc(GB);

    for (i = 0; i < TEST_SIZE; i++)
        free(p[i]);
}

int main(void)
{
    system("free -mh");
    printf("\n\n");

    rapemem(0);
    rapemem(1);
    rapemem(0);

    return 0;
}

Выхлоп:

alex@alex-thinkpad-l560:~/Разработка/C/Tests/calloc$ gcc -std=c89 poc.c 
alex@alex-thinkpad-l560:~/Разработка/C/Tests/calloc$ ./a.out 
              total        used        free      shared  buff/cache   available
Память:        7,6G        2,1G        4,2G        396M        1,2G        4,8G
Подкачка:          0B          0B          0B


Switching zerofy to 0
 * Allocated 1073741824 bytes [0x7fe248a9b010]
 * Allocated 1073741824 bytes [0x7fe208a9a010]
 * Allocated 1073741824 bytes [0x7fe1c8a99010]
 * Allocated 1073741824 bytes [0x7fe188a98010]
 * Allocated 1073741824 bytes [0x7fe148a97010]
 * Allocated 1073741824 bytes [0x7fe108a96010]
 * Allocated 1073741824 bytes [0x7fe0c8a95010]
 * Allocated 1073741824 bytes [0x7fe088a94010]
 * Allocated 1073741824 bytes [0x7fe048a93010]
 * Allocated 1073741824 bytes [0x7fe008a92010]
Switching zerofy to 1
 * Allocated 1073741824 bytes [0x7fe248a9b010]
 * Allocated 1073741824 bytes [0x7fe208a9a010]
 * Allocated 1073741824 bytes [0x7fe1c8a99010]
 * Allocated 1073741824 bytes [0x7fe188a98010]
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
 * Cannot alloc 1073741824 bytes
Switching zerofy to 0
 * Allocated 1073741824 bytes [0x7fe248a9b010]
 * Allocated 1073741824 bytes [0x7fe208a9a010]
 * Allocated 1073741824 bytes [0x7fe1c8a99010]
 * Allocated 1073741824 bytes [0x7fe188a98010]
 * Allocated 1073741824 bytes [0x7fe143fff010]
 * Allocated 1073741824 bytes [0x7fe103ffe010]
 * Allocated 1073741824 bytes [0x7fe0c3ffd010]
 * Allocated 1073741824 bytes [0x7fe083ffc010]
 * Allocated 1073741824 bytes [0x7fe043ffb010]
 * Allocated 1073741824 bytes [0x7fe003ffa010]

WTF вообще? Теперь и calloc выделению доверять нельзя? Да здравствуют SIGSEGV без вариантов проверить выделение?

Я знаю про оптимистичное выделение, но всю жизнь эта ботва была только с malloc, calloc от этой херни был свободен так как занулял память.

★★★★★

Последнее исправление: PPP328 (всего исправлений: 1)
Ответ на: комментарий от Deleted

Что за векторы?

std::vector, да и не важно какие. Подобное есть в любом «автоматическом» дин-массиве.

Что за поток сознания?

В чём именно поток? Поподробнее. Что именно тебе непонятно?

О чем это вообще?

О разнице между убогими и протухшими моделями, представлениями и реальностью.

rustonelove
()
Ответ на: комментарий от Deleted

в смысле заливать? ты не видел ни разу как компилятор выкидывает non-observable код?

dzidzitop ★★
()
Ответ на: комментарий от Deleted

Стоимость языковых конструкций в тактах или времени не определена. Так что тут сложно не согласиться с rustonelove.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

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

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

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

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

rustonelove
()
Ответ на: комментарий от rustonelove

И причина проста - неверные представления о реальности. Поэтому и приходиться страдать хернёй и выбирать «какой же коэффициент поставить вектору?». У них там целые баталии на этот счёт. Их не волнует, что ставь хоть х10 - это ничего не поменяет, кроме того, что станет только лучше.

Для размеров вектора в районе нескольких страниц памяти может и станет типо лучше. А для векторов на 10 элементов это однозначно хрень. Потому что количество занятых процессом страниц памяти будет перерасходовано.

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

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

man malloc. Найди там что-нибудь про то, что она возвращает память, за которой ничего нет. Вдруг найдёшь.

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

сначала этот васянистый код будет заинлайнен

Заинлайнен. Из другой единицы компиляции. Ага, щаз.

Deleted
()
Ответ на: комментарий от rustonelove

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

С логикой дружишь? Если да, то ты говоришь, что компилятор может удалить инициализацию с последующей реинициализацией (spatial relation). И при этом он забивает на 100% на temporal relation.

А уж о чём я знаю - не тебе судить. Судя по всему, навык читать спеки ты не осилил.

dzidzitop ★★
()
Последнее исправление: dzidzitop (всего исправлений: 2)
Ответ на: комментарий от Deleted

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

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

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

Не будет. Тебе надо научиться понимать тему, а не нести ахинею, ретранслируя агитки.

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

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

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

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

Но а) подобные кейсы фантаистические. б) они так же требуют динамического выделения памяти, ведь это «долгое время» программа должна что-то вычислять. Не факториалы же. в) можно ещё с вести этот кейс к какому-то io, которое уже не будет требовать дополнительной памяти. Но опять же - фантастика.

https://godbolt.org/g/hcSiUG - как мы видим, ни один из компилятор даже самый примитивный паттерн реинициализации не видит.

Это именно проблемные паттерны, если мы берём время выполнения f() - много. То оно отвалиться после, а не сразу как с мемсетом. Но это мало что меняет и никаких проблем не вызывает, кроме падения «не вовремя».

Хотя, может быть и наоборот. Может быть так, что сейчас памяти нету, а потом будет. Т.е. даже не факт, что это плохо.

rustonelove
()
Ответ на: комментарий от dzidzitop

Ты того не догоняешь, что твой формальный «исполнитель» находится внутри процесса ОС, и за пределы его внутренней среды спецификация не распространяется.

А в спецификации нет НИЧЕГО ни про нижележащую модель памяти, ни про гарантию завершения исполнения какого-либо кода кем-либо. И было бы странно, если бы это там было.

Электрик Вася отключил рубильник или админ Петя послал SIGKILL — всё это факторы за пределами области определения рантайма прикладухи. Или ядро само послало SIGKILL. Или это сделал скрипт по велению левой пятки админа. Или процессор вышел из строя. Или на компьютер упал метеорит.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

А для векторов на 10 элементов это однозначно хрень.

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

Мантра о магической экономии - никого не интересует. Ты в реальных условиях даже 1-2к еле сэкономишь, да даже если сэкономишь и 4к на ветор - это мало кого волнует.

Пере однозначно - надо подумать, а не нести ахинею. Такие дела.

rustonelove
()
Ответ на: комментарий от rustonelove

никаких проблем не вызывает, кроме падения «не вовремя».

это «не вовремя» и есть единственной проблемой, с парочкой наведённых доп. проблем


Хотя, может быть и наоборот. Может быть так, что сейчас памяти нету, а потом будет. Т.е. даже не факт, что это плохо.

плохо - это когда, читая исходник, нельзя вывести то, что он безотказен.

А то, что эти граничные случаи редко представляют проблему не означает, что на них можно закрывать глаза. Писать платформоспецифичный код - не всегда хорошее решение. Хотя можно сделать свой какой-нибудь alloc_n_init() и не использовать библиотеки в местах, где нужны гарантии.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

man malloc. Найди там что-нибудь про то, что она возвращает память, за которой ничего нет. Вдруг найдёшь.

malloc(3)

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer.

deadskif
()
Ответ на: комментарий от dzidzitop

С логикой дружишь? Если да, то ты говоришь, что компилятор может удалить инициализацию с последующей реинициализацией (spatial relation). И при этом он забивает на 100% на temporal relation.

Поподробнее. Что и из чего следует. Из чего следует то, что я с логикой не дружу. Как обычно. Обосрался - накидай рандомных базвордов в несвязной портянки из которой ровным счётом ничего не следует.

А уж о чём я знаю - не тебе судить. Судя по всему, навык читать спеки ты не осилил.

Я могу судить и уже сужу. С примером выше ты обосрался, как и со всем остальным. Если бы что-то понимал, то не обосрался бы. Всё логично, просто и понятно.

Поэтому твои рассуждения о том, что я могу, либо не могу - пустой трёп.

rustonelove
()
Ответ на: комментарий от rustonelove

Включаешь мозг и используешь capacity. Работает лучше 10x увеличения.

Экономия никого не интересует - используй скайпы, которые жрут реальной памяти по гигабайту.

А я в кэшах данных в разы потребление памяти уменьшал при помощи некоторых приёмов по уменьшению количества указателей и неиспользуемой преаллоцированной памяти.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

это «не вовремя» и есть единственной проблемой, с парочкой наведённых доп. проблем

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

плохо - это когда, читая исходник, нельзя вывести то, что он безотказен.

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

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

Означает. Никакой проблемы в рамках логики си - там нет. Ты это сам придумал. Да и их вообще нет.

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

Писать платформоспецифичный код - не всегда хорошее решение.

Это всегда хорошее решение в ситуации, когда у тебя открытая и универсальная платформа. Да и по другому ты это не сделаешь.

rustonelove
()
Ответ на: комментарий от dzidzitop

плохо - это когда, читая исходник, нельзя вывести то, что он безотказен.

Что значит «безотказен»?

Deleted
()
Ответ на: комментарий от rustonelove

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

Пруфов о запрете от тебя уже не будет - я понял. Кто треплется - попробуй догадаться.

dzidzitop ★★
()
Ответ на: комментарий от rustonelove

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

Благородный д'Артаньян.

Цитирую себя

Calloc нынче ни на что не влияет что-ли? (комментарий)

Гарантий, что память будет в полном пользовании программы перед циклом - нет. Т.е. через 100 лет, когда цикл пройдёт, может быть фриз на обращении к памяти после цикла. А сам код на месте цикла может запускать какую-то производственную процедуру, и после него код должен работать как часы.
А компилятору можно выкинуть memset, т.к. этот memset не имеет побочных эффектов с точки зрения компилятора языка C.




А тебя, о благородный муж, приглашаю пройти в сад.

dzidzitop ★★
()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

Включаешь мозг и используешь capacity. Работает лучше 10x увеличения.

В потоке, ога. Ты пытаешься юлить. Если у тебя есть capacity, то нахрена в векторе вообще логика реаллокации? Ты там дыру-то в логике зашей. Это пустой трёп.

Экономия никого не интересует - используй скайпы, которые жрут реальной памяти по гигабайту.

Опять же, это не экономия, а херня. К экономии это никакого отношения не имеет.

А я в кэшах данных в разы потребление памяти уменьшал при помощи некоторых приёмов по уменьшению количества указателей и неиспользуемой преаллоцированной памяти.

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

Я тебя сейчас попрошу мне пример выкатить и ты перданёшь в лужу.

Кстати, ты там уже деревья/списки с оверхедом 16байт+ на ноду выкинул? Агитка про это не рассказала? Бывает, когда балаболишь.

rustonelove
()
Ответ на: комментарий от Deleted

в данном случае - гарантия выполнения за определённое, статически известное worst case время. Хотя требовать такое не в RT окружении, конечно, самонадеянно. Поэтому можно ввести доверительную вероятность исполнения за worst case время.

dzidzitop ★★
()
Ответ на: комментарий от rustonelove

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

Балабол, вот тебе пример такой экономии на C++:

https://github.com/dzidzitop/gravifon_lastfm_scrobbler_deadbeef_plugins/blob/...

Если не осилишь прочитать код - ничего страшного.

А теперь успокойся, выдохни - и занимайся своим кукареканьем и дальше. Только без меня.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

Цитирую себя

И тут же обсираюсь. Т.к. эта потуга не имеет никакого отношения к теме.

А компилятору можно выкинуть memset, т.к. этот memset не имеет побочных эффектов с точки зрения компилятора языка C.

Компилятор может выкинуть и маллок и обращение к памяти, т.к. оно смысла не имеет.

Смотрим примеры мои и ламерка.

Идём далее:

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

Что значит эта ахинеия мне неясно. Давай я тебе задам простой вопрос. Что произойдёт после цикла в твоём примере и в чём именно проблема. Отвечай.

rustonelove
()
Ответ на: комментарий от dzidzitop

в данном случае - гарантия выполнения за определённое, статически известное worst case время.

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

Хотя требовать такое не в RT окружении, конечно, самонадеянно.

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

Поэтому можно ввести доверительную вероятность исполнения за worst case время.

А доверительная вероятность сжирания соседним процессом пары десятков гигабайт ОЗУ и уход системы в трашинг навечно до хард ресета - где именно в твоём коде будет записана?

Deleted
()
Ответ на: комментарий от dzidzitop

Балабол, вот тебе пример такой экономии на C++:

Обожаю ламерков. Обосрался, выкатил левую херню, на вопросы не ответил и никак то, что выкатил с контекстом и своим предыдущим кукаретингом не связал.

Если не осилишь прочитать код - ничего страшного.

Обожаю, когда ламерки со своими убогими хелвордами рассказывают мне про «не осилишь».

Особенно после этого:


	std::size_t m_artistsBegin;//ога, 64битные офсеты в тегах
	std::size_t m_albumTitleBegin;
	std::size_t m_albumArtistsBegin;
	// Track duration in milliseconds.
	long m_durationMillis;//ламерок не вырос из 386. 

Кстати, ламерок. Что ты хотел показать своей хелворд-скрингой? Поподробнее? Это же обычное хелворд-дерьмо на маллоке.

rustonelove
()
Ответ на: комментарий от Deleted

А доверительная вероятность сжирания соседним процессом пары десятков гигабайт ОЗУ и уход системы в трашинг навечно до хард ресета - где именно в твоём коде будет записана?

Соседние процессы можно ограничить по потреблению памяти и CPU.

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

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

Соседние процессы можно ограничить по потреблению памяти и CPU.

Тогда в эту тему заглянет разработчик кода из этого «соседнего процесса» с той же претензией, что и у тебя: «Васян, хде мои гарантии,э? А если найду?»

Ядро вот ограничило твои требования к памяти некоторым разумным значением, а ты недоволен.

Deleted
()
Ответ на: комментарий от dzidzitop

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

/лицоладонь

Что только не придумать, лишь бы не делать по уму, ага?

Deleted
()
Ответ на: комментарий от dzidzitop

Соседние процессы можно ограничить по потреблению памяти и CPU.

Допустим, ты их ограничил. Памяти тебе хватает. Оомкиллер к тебе в гости не придёт. И в чем твоя претензия?

Deleted
()
Ответ на: комментарий от dzidzitop

Так, ну погнали. Читаем первоисточник: Calloc нынче ни на что не влияет что-ли? (комментарий)

А именно:

Нельзя просто так взять и выпилить мемсет. Его можно выпилить тогда, когда ты инициализируешь память после и именно в этом контексте это и было в той агитке. Это именно «проблема» безопасности.

Далее, ламерок начал отвечать на это какой-то ахинеей:

Компилятор может делать всё, что ему не запрещено. Такие оптимизации ему не запрещены.

И это ламерку я чётко и ясно ответил:

Запрещены.

И ясно и понятно что тут и почему. Ламерку определили, что просто так выпиливать никакие мемсеты нельзя - их можно выпиливать только в определённых кейсах. Далее ламерок начал кукарекать о том, что:

Компилятор может делать всё, что ему не запрещено. Такие оптимизации ему не запрещены.

Т.е. он явно спорит с тем, что просто так их выпиливать нельзя. В противном случае его ответ не имеет смысла.

И ему чётко и ясно дали ответ, что в рамках той шизофрении, которую несёт ламерок, компилятору запрещены подобные оптимизации.

Теперь ламерок начинает врать, а именно говорить то, что я СЕЙЧАС начал говорить о случаях, но - именно это и было описано в первоисточнике, ещё до «запрещено». Т.е. балаболка явно врёт.

Пруфов о запрете от тебя уже не будет - я понял. Кто треплется - попробуй догадаться.

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

И самое интересное, что именно этот ламерок начал балаболить о том, что «не запрещено», но пруфов никаких не дал, ссылаясь на - «то, что не запрещено - разрешено», но у нигде никакие запреты не определены - это ламерок сам придумал.

rustonelove
()
Ответ на: комментарий от dzidzitop

Уже даже в этой теме предлагалось чуть ли не с десяток вариантов и их комбинаций, начиная от настройки ядра и заканчивая mlock().

Но мы же не ищем лёгких путей?

Deleted
()
Ответ на: комментарий от Deleted

Уже десятки там эксперты срутся на тему - какой же коэффициент поставить в ресайз. Там целые баталии были и есть на этот счёт.

rustonelove
()
Ответ на: комментарий от Deleted

Это ты же давал пример аллокации 100GiB памяти выше где-то? Ну так сам процесс может переаллоцировать себе памяти насколько, что потом физической памяти не хватит в нужный момент. И будет нежданчик.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

Вот это самое интересное. Ламерки кукарекают про реаллок, а на самом деле:

https://github.com/dzidzitop/libafc/blob/master/src/afc/SimpleString.hpp#L199

Ну бывает.

По поводу самого реаллока - я же там чётко и ясно сказал «не нужен». «не нужен» - это не про замену - это про отказ. Это в словарике написано.

rustonelove
()
Ответ на: комментарий от dzidzitop

Этот пример давал я. И самое интересное - зачем ты пытаешься что-то балаболить, если нихрена не понимаешь и даже не способен понять что было показано тем примером.

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

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

rustonelove
()
Ответ на: комментарий от rustonelove

Нельзя коэффициент, только постоянное слагаемое!

anonymous
()
Ответ на: комментарий от dzidzitop

И будет нежданчик.

Так, лимиты процессам ставить мы научились. Хорошо. Осталось научиться в /proc/sys/vm/overcommit_memory и /proc/sys/vm/overcommit_ratio, и ты почти разрешил неразрешимую «проблему».

Deleted
()
Ответ на: комментарий от rustonelove

Ох ты, он еще и на темплейтах!

Всегда мечтал создать string of unsigned long long, лол.

Deleted
()
Ответ на: комментарий от rustonelove

Проблема в том, что твой 32битный мипс не нужен.

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

Ну расскажи мне про свой кейс

Ух как быстро перевел стрелки. Это ты собирался рассказать почему realloc не нужен, а я хотел послушать.

pftBest ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.