стиль обработки ошибок

спутали return c result? :)

Помню, у нас в команде был забавный парнишка, который всюду таскал за собой h-файл собственного сочинения, в котором чуть ли не первыми двумя строками были define'ы TRUE и FALSE (да, именно так, в верхнем регистре).

Так что вероятность есть, и ненулевая. :)

можно - но тогда деструктор должен точно знать или анализировать степень изменения состояния выполнения функций

а что у тебя там анализировать? Пока видно только выделение памяти и её освобождение при неудачном выполнении. Пусть даже скажем обобщённо - освобождение ресурсов.

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

Во всяком случае, с goto в функции со сложной логикой накосячишь гораздо быстрее чем сделаешь «прозрачный» деструктор.

если это не один обьект - а общая среда программы

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

есть подозрение, что автору не нужно освобождать ресурсы если все ок, походу p1 и p2 глобальные переменные? :D

1) Помимо освобождения структуры у обработчика ошибки могут быть и другие действия.

2) При нормальном вызове деструктора if'ы явно лишние.

Кстати, просветите, что будет, если попытаться с помощью free() освободить неаллоцированную память?

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

Во всяком случае, с goto в функции со сложной логикой накосячишь гораздо быстрее чем сделаешь «прозрачный» деструктор.

Мужички-ядрописцы что-то пишут и не косячат

Я писал код на Basic на 8-ми битной платформе. Там были goto, но как неизбежное зло, ибо небыло ни try..except, ни исключений.

а что у тебя там анализировать? Пока видно только выделение памяти и eё освобождение при неудачном выполнении. Пусть даже скажем обобщённо - освобождение ресурсов.

ну смотри - уж коли ты о обьектах говориш
вызов метода обьекта - должен изменить состояние обьекта
но что если при выполнении ошибка произошла - должен ли метод откатывать изменения - или оставит работу на полпути ? типа деструктор все решит

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

Кстати, просветите, что будет, если попытаться с помощью free() освободить неаллоцированную память?

будет шмяк :)

Кстати, просветите, что будет, если попытаться с помощью free() освободить неаллоцированную память?

Смотрим стандарт:

7.20.3.2 The free function

The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if the argument does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined.

Этого достаточно?

1) Помимо освобождения структуры у обработчика ошибки могут быть и другие действия.

да неужели? Кто бы мог подумать...

) При нормальном вызове деструктора if'ы явно лишние.

и что же это такое, нормальный вызов деструктора?

Мужички-ядрописцы что-то пишут и не косячат

Что если таки взять и посмотреть как они пишут?

Вполне. Спасибо

НеДумай@пиши?

Простой пример: чтение фреймов данных из потока. В начале каждого фрейма - sync-последовательность, по которой можно определить начало фрейма. Функция-читатель возвращает массив успешно прочитанных фреймов

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

и что же это такое, нормальный вызов деструктора?

Вызов в нормальной ситуации (не при обработке ошибки).

Что если таки взять и посмотреть как они пишут?

Да, возьми и посмотри по моей ссылке и не бзди лишний раз

хороший ли это стиль для Си или нет ?

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

такой стиль принят (как тут уже сказали) в ядрах. В частности из-за отсутствия тормозных throw/catch

получается очень красиво и никаких спагетти - если происходит ошибка, то просто переменной возврата присвайваешь определенное значение и goto на соответсвующую метку. А в конце все красиво разворачивается:

    ...
    if ((ret = mkopci_create_proc_entry())) {
        printk(KERN_ERR"mkopci: error creating proc entries\n");
        goto unreg_drv;
    }    
    goto out; 

unreg_drv:
    pci_unregister_driver(&mkopci_pci_driver);
free_chr_reg:
    unregister_chrdev_region(devp, MAX_DEVICES_NR);
destoy_class:
    class_destroy(mkopci_class);
destroy_cache:
    while (!list_empty(&devices)) {
        d = list_entry(devices.next, mkopci_device_t, list);
        list_del(devices.next);
        kmem_cache_free(mkopci_device_cache, d);
    }    
    kmem_cache_destroy(mkopci_device_cache);

out:
    return ret; 
}

да, сорри

есть подозрение, что автору не нужно освобождать ресурсы если все ок, походу p1 и p2 глобальные переменные?

даже если глобальные, выделяются все равно в функции

Один из тех случаев где гоуту полезен. Стиль хороший.

Код для захвата и освобождения ресурсов в случае ошибки в стиле ТС не похож на макаронную фабрику. Всё чисто, понятно и логично. А главное занимает мало места и работает быстрее не придумаешь.

В том-то и дело, что в Си с исключениями тоже все плохо

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

https://github.com/torvalds/linux/blob/master/Documentation/CodingStyle#L386