История изменений

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

Вот поэтому и надо проверять результаты malloc-а и адекватно реагировать на них. Как минимум — рухнуть, изложив все проблемы в stderr. А вообще можно и продолжить работать, если уверен в том, что программа и её составляющие работают корректно.

Поэтому любой I/O меня уже настораживает, не говоря уже о более развесистых алгоритмах.

А какие проблемы в I/O могут быть? Очевидно все стандартные функции должны работать нормально, даже если malloc возвращает NULL. Т.е. они могут вернуть ошибку, что не хватило памяти и эту ошибку надо обработать адекватно. Но какой-то порчи буферов и тд быть не должно. В нормально написанном клиентском коде всё будет работать нормально. Например ты пишешь сетевой сервер, обрабатывающий запросы. Не хватило памяти какому-то запросу — верни клиенту индикацию того, что сервер перегружен и надо послать запрос попозже, обработке остальных запросов это не помешает.

Другой вопрос — что при проверке всех выделений памяти код усложняется, это всё обычно никто не тестирует и тд. Поэтому может быть проще тупо брякнуться и построить архитектуру, при которой это нормально. Например на каждый запрос стартует отдельный процесс, упадёт — и фиг с ним. Клиент получит RST и через некоторое время повторит запрос. Так писать проще, но не всегда это возможно.

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

Вот поэтому и надо проверять результаты malloc-а и адекватно реагировать на них. Как минимум — рухнуть, изложив все проблемы в stderr. А вообще можно и продолжить работать, если уверен в том, что программа и её составляющие работают корректно.

Поэтому любой I/O меня уже настораживает, не говоря уже о более развесистых алгоритмах.

А какие проблемы в I/O могут быть? Очевидно все стандартные функции должны работать нормально, даже если malloc возвращает NULL. Т.е. они могут вернуть ошибку, что не хватило памяти и эту ошибку надо обработать адекватно. Но какой-то порчи буферов и тд быть не должно. В нормально написанном клиентском коде всё будет работать нормально. Например ты пишешь сетевой сервер, обрабатывающий запросы. Не хватило памяти какому-то запросу — верни клиенту индикацию того, что сервер перегружен и надо послать запрос попозже, обработке остальных запросов это не помешает.

Другой вопрос — что при проверке всех выделений памяти код усложняется, это всё обычно никто не тестирует и тд. Поэтому может быть проще тупо брякнуться и построить архитектуру, при которой это нормально. Например на каждый запрос стартует отдельный процесс, упадёт — и фиг с ним. Так писать проще, но не всегда это возможно.

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

Вот поэтому и надо проверять результаты malloc-а и адекватно реагировать на них. Как минимум — рухнуть, изложив все проблемы в stderr. А вообще можно и продолжить работать, если уверен в том, что программа и её составляющие работают корректно.

Поэтому любой I/O меня уже настораживает, не говоря уже о более развесистых алгоритмах.

А какие проблемы в I/O могут быть? Очевидно все стандартные функции должны работать нормально, даже если malloc возвращает NULL. Т.е. они могут вернуть ошибку, что не хватило памяти и эту ошибку надо обработать адекватно. Но какой-то порчи буферов и тд быть не должно. В нормально написанном клиентском коде всё будет работать нормально. Например ты пишешь сетевой сервер, обрабатывающий запросы. Не хватило памяти какому-то запросу — верни клиенту индикацию того, что сервер перегружен и надо послать запрос попозже, обработке остальных запросов это не помешает.

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

Вот поэтому и надо проверять результаты malloc-а и адекватно реагировать на них. Как минимум — рухнуть, изложив все проблемы в stderr. А вообще можно и продолжить работать, если уверен в том, что программа и её составляющие работают корректно.

Поэтому любой I/O меня уже настораживает, не говоря уже о более развесистых алгоритмах.

А какие проблемы в I/O могут быть? Очевидно все стандартные функции должны работать нормально, даже если malloc возвращает NULL. Т.е. они могут вернуть ошибку, что не хватило памяти и эту ошибку надо обработать адекватно. Но в нормально написанном клиентском коде всё будет работать нормально.