Си: прилично ли передавать в функцию указатели, заполненные мусором после malloc?

Принято ли так делать

Нет, не принято. На примере изображений: создание по размерам «нулевого» изображения, только потом его передача.

Говорят что malloc вообще неприлично использовать при наличии calloc.

Чем больше UB - тем лучше.

Да. Читаю сейчас книгу Extreme C. Там именно так и делается

person_t* person = person_new();

person = person_ctor(age, birth_year);

Функция person_new возвращает указатель от malloc, а конструктор (person_ctor) заполняет объект.

Эта другая функция сама память выделить не может? Вообще здесь нет ничего криминального, но не совсем понятна необходимость так делать.

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

Вполне нормально, почему нет?

Например:

ArrayInt arr;

arrIntInit(&arr, 10); выделили память под 10 элементов

arrIntFill(&arr, 0xffff); // заполняем значениями

// ...

Или я не так понял вопрос?

Эта другая функция сама память выделить не может?

А зачем функции знать, какая память ей передана - стек ли, статика ли, либо куча?

Тебе - можно.

Если функция читает из этой памяти — это однозначно плохо. Если пишет туда — никакого криминала не вижу, всё равно все данные будут перезаписаны

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

Хорошим тоном будет иметь не 1 а 3 таких функции.

• Превая просто выделяет память (аля malloc)
• Вторая выделяет память с дефолтным значением заполения (аля calloc)
• Третья выделяет и заполняет значением пользователя (аля memset)

Имена должны быть одинаковы с пре или постфиксами для второй и третьей.

Но это базово. Можно придумать по разному. Да и порой таки надо принудительно очищать память тем или иным значением. Хз. Короче.

Вопрос чисто про культуру.

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

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

Херова гора ::) Опиши точнее что выделяется, куда и для чего. Я те нагенерирую вариков. Но потом я спать.))

Так это я спрашиваю, для чего. Коротко говоря, если я допустим пишу свой стандарт MISRA, могу ли я туда вписать запрет на такую передачу и с какими оговорками. Похоже, придётся пойти и почитать MISRA.

Коротко говоря, если я допустим пишу свой стандарт MISRA, могу ли я туда вписать запрет на такую передачу

#define malloc(x) calloc(1, x)

хватит всем

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

Зависит от того, что эта функция с ней делает. Может и не надо.

прилично, в winapi и разного рода либах так часто делают, что бы функция не зависила от имплементации аллокатора

А зачем функции знать, какая память ей передана - стек ли, статика ли, либо куча?

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

Другое дело, что не всегда можно заранее определить, сколько выделять. Если выделяется только базовая структура, в которой ещё куча указателей на дополнительные объекты, выделяемые дочерней функцией — выгода такого решения становится неочевидной. Всё равно для освобождения придётся отдельную функцию писать…

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

Спасибо! Собственно, на этом тема вроде как исчерпана.

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

А как по другому инициализировать объекты? Запретить кастомные аллокаторы? Или городить для них отдельно какой-нибудь интерфейс?

В правилах можно потребовать, чтобы аллокаторы как-то особенно помечались.

В большинстве случаев сам чистишь, дальше передаешь в функцию указатель. Как минимум так сделано в OpenSSL, больше Сишных библиотек не помню.

ИМХО всё хорошо пока ты выделяешь память и высвобожаешь в одном и том же блоке, а касательно вопроса - это вопрос соглашения и прилично такое или нет будет зависеть от проекта - главное придерживаться одного стиля. Также в библиотеках желательно оборачивать malloc и free в что-то типа libname_malloc и libname_free, дабы в любое время свободно менять способ выделения памяти во всей библиотеке.

Моё мнение что это очень даже нормально, если к примеру формируется единый интерфейс работы с объектом:

void matrix_alloc(int n, int m, double **mat);
void matrix_free(double *mat);
void matrix_ones(int n, int m, double *mat);
void matrix_identity(int n, int m, double *mat);
...
int  main()
{
    ...
    int m = 224;
    int n = 224;
    double *A;
    matrix_alloc(n, m, &A);
    matrix_ones(n, m, A);
    ...
    matrix_free(A);
    ...
}

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

Какие еще аллокаторы? Память если и должна выделятся, то только один раз в начале! А с матрицами это на фортран.

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

Убивать!

Особенно для буфера в который будет сокет писать?

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

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

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

Это ясно только для единовременно написанного кода, который никогда никто не меняет/расширяет. Обнуление структуры сразу после создания позволит в будущем спокойно эту структуру расширять без риска забыть какие-то поля доинициализировать, или написать другую функцию, которая будет инициализировать по-другому и частично – опять же без риска получить не до конца инициализированный объект. Совершенно неимоверное количество человекочасов потрачено многими людьми на отлов таких багов, которых можно было избежать при использовании при использовании calloc() или malloc() + memset() вместо простого malloc(). Плюс, надо учесть, что с одним и тем же кодом работают разные люди – всем заморачиваться вопросом, как именно выделили память под структуру? Это будет непродуктивный расход времени.

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

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

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

Говорят что malloc вообще неприлично использовать при наличии calloc.

Кто тебе такую ерунду сказал?

Поклонники rust же. Мало того что calloc не вернёт область памяти где ключи лежали, так ещё и корректнее отработает ситуацию когда результат перемножения размера типа данных на количество в size_t не пролазит.

Мало того что calloc не вернёт область памяти где ключи лежали

malloc тоже не вернёт ничего такого.

Есть два случая:

1. malloc возвращает новую память: mmap возвращает обнулённую память

2. malloc возвращает память которая была использована и освобождена free, но если мы беспокоемся о ключах, то мы сами обнулили ту память. А если не обнулили, то ту память и так считают и без malloc. Так что разницы нет.

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

On embedded Linux, malloc could mmap(MAP_UNINITIALIZED|MAP_ANONYMOUS), which is only enabled for some embedded kernels because it’s insecure on a multi-user system.