[C] free(p) vs. if(p) free(p)

очевидно, что первый. всё остальное от лукавого.

http://www.opengroup.org/onlinepubs/009695399/functions/free.html

// wbr

Очевидно же, второй.

Первый, второй не обязателен

> Очевидно же, второй.

можно услышать обоснование сделанного выбора? своё я привёл выше.

// wbr

Удобнее модификация кода.

> Удобнее модификация кода.

не понял. можно развернуть ответ?

// wbr

Ну, во первых, частенько они изначально в форме if else идут для целей разработки, во вторых, if (p) { free(p); smth(); } иногда требуются (да, кавычки я тоже добавляю, т.е. 
if (p) {
  free(p);
}
изначально). Как то так.

В догонку:

typedef struct {int a} mydata;

1. mydata *p = malloc(sizeof *p);
2. mydata *p = malloc(sizeof(mydata));

какой вариант лучше/портабeльнее/эстетиченее? IMHO 1.

> Ну, во первых, частенько они изначально в форме if else идут для целей разработки, во вторых, if (p) { free(p); smth(); } иногда требуются (да, кавычки я тоже добавляю, т.е.
if (p) {
free(p);
}
изначально). Как то так.

то, что уже кем-то написано [и работает] по всей видимости лучше не трогать - выгода будет минимальной. хоть так хоть так. однако, AFAIU автор спрашивал на тему нового кода и тут ставить явную проверку на != NULL особого смысла нет, только лишний оверхед [впрочем, небольшой] и явно лишний код, что в т.ч. сказывается на читабельности.

// wbr

>if(p) free(p)

В Си это в общем случае некорректно, т.е. NULL не всегда == 0.

В Си++ - в ранних реализациях (не помню, когда в стандарте определили, что NULL == 0) - аналогично.

>то, что уже кем-то написано [и работает]

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

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

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

в том то и проблема, что 2й способ ровным счётом ни от чего не спасёт и с точки зрения повышения надёжности кода ничего не даёт. free(3) и так явным образом проверяет переданный ему указатель на NULL и ничего не делает, если он NULL. в полном соответствии с документацией. какой смысл делать это дважды?

// wbr

>В догонку:

>typedef struct {int a} mydata;

>1. mydata *p = malloc(sizeof *p);
>2. mydata *p = malloc(sizeof(mydata));

>какой вариант лучше/портабeльнее/эстетиченее? IMHO 1.

IMHO тоже 1, т.к. писать меньше :)

всегда найдутя варианты применения обоих вариантов

> в полном соответствии с документацией. какой смысл делать это дважды?

Проблема в том, что не везде. У нас были компиляторы не воспринимающие C++ комментариев, а уж free(NULL) не воспринимают многие libc. Кстати AC_STDC_HEADERS проверяет поведение free и malloc и создает свои версии в случае их несоответствия стандарту.

       free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc().  Otherwise,
       or if free(ptr) has already been called before, undefined behavior occurs.  If ptr is NULL, no operation is performed.

Правильно делаешь. free() проверяет значение на нулевой указатель, и если он является таковым, ничего не делает. Смысла в лишней проверке нет.

>В Си это в общем случае некорректно, т.е. NULL не всегда == 0.

Последние системы где нулевой указатель не был эквивалентен бинарному нулю умерли где-то в 70х-80х и больше не появятся никогда.

По теме - проверка if(p) абсолютно излишняя, т.к free и delete проверяют параметр на null.

>Последние системы где нулевой указатель не был эквивалентен бинарному нулю умерли где-то в 70х-80х и больше не появятся никогда.

Я на такой в 1990-х работал. Только не помню уже, Zortech это был или Watcom какой-то. Товарищ у меня и сегодня на такой системе работает. Мир не кончается на GCC и VC :) И в некоторых случаях NULL != 0 оправдан. Например, для генерации аппаратных исключений на платформах, где можно читать с нулевого адреса.

An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.

в си есть система типов и ноль (константный на этапе компиляции) будет автоматически трактован правильно, даже если бинарное представление NULL ненулевое.

Проблема возникнет только если есть целочисленная переменная равная нулю и ты сравниваешь указатель с ней.

Фигасе, а у меня почему-то сложилось стойкое представление, что с delete оно можно, а с free нельзя. =O Уже и не вспомню где вычитал такое. Как страшно жить! )

С XFree нельзя =)

вопрос в том, во всех ли реализациях free() (не только в libc) осуществляет проверку на NULL?
для кроссплатформенности, думаю, второй вариант

>вопрос в том, во всех ли реализациях free() (не только в libc) осуществляет проверку на NULL? для кроссплатформенности, думаю, второй вариант

Не на всех, лично сталкивался с такой подколкой. Кажется, на FreeBSD.

> вопрос в том, во всех ли реализациях free() (не только в libc) осуществляет проверку на NULL? для кроссплатформенности, думаю, второй вариант

вопрос в том, готовы ли вы загромождать свой код ненужными конструкциями ради абстрактной совместимости с платформами, которые не следуют стандарту C [даже не POSIX]? если есть такая реальная необходимость - куда деваться. если же нет и всё на уровне "где-то может быть и так" то IMHO не стоит. в противном случае, можно придумать ещё пару сотен "фич" которые в силу миллиона причин по разному работают тут и там и превратить стройный код проекта в подобие внутренностей ACE.

// wbr

>в си есть система типов и ноль (константный на этапе компиляции) будет автоматически трактован правильно, даже если бинарное представление NULL ненулевое.

Т.е. if(p), где p == ненулевому NULL отработается корректно? В тех компиляторах, с которыми я сталкивался и в котором упомянутый товарищ работает это не прокатывало :) Только прямое сравнение if(p != NULL) ...

svobodu NULL!!!

>Не на всех, лично сталкивался с такой подколкой. Кажется, на FreeBSD.

Оно еще не RIP?

Использую второй вариант.
Как бы жрать не просит.