Как стать автором
Обновить

Комментарии 21

Программа положила вывод в stdout? Положила. У неё это получилось? Получилось. Перенаправление stdout в файл это не функция программы, а функция оболочки (shell).

Если у shell не получилось, он и должен поправить код ошибки.

У программы не получилось, она просто проигнорила код ошибки.
А еще вы не знаете как работает перенаправление.

Начнём с того, что это перевод, поэтому за автора ответить не смогу.

Как вы смотрите на то, что некоторые программы из таблицы считают это ошибкой? Или на то, что в Python2 это игнорируется, а в Python3 нет? Разработчики Python3 заблуждаются? Пример с обрезанным yaml тоже интересный.

Поэтому и перевёл, что тема не однозначная.

У неё это получилось? Получилось.

Почему вы так решили?

Смотрим документацию puts для примера на C:

If successful, non-negative value is returned. On error, the function returns EOF.

Достаточно просто вернуть это значение вместо того чтобы всегда возвращать 0, чтобы убедиться что не "получилось".

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

int main(void)
{
  return puts("Hello World!");
}

Для /dev/null вернётся 0, а для /dev/full вернётся 10. Т.е. у программиста получилось проигнорировать ошибку, а не у программы получилось что-то сделать.

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

Статья как раз о том что они есть. Даже в hello world. Ну и не стоит её так серьёзно воспринимать, зато есть что подчерпнуть. Я, например, узнал что есть /dev/full. Потом узнал что его нет в macOS.

То есть в macos баг не воспроизводится, тикет можно закрывать? ;)

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

Задокументированный баг становится фичей ;)

Давайте по порядку. Напомню вам ваши же слова:

Программа положила вывод в stdout? Положила. У неё это получилось? Получилось.

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

Потому что вы не описали требования к программе.

Строго говоря, я вообще ничего не описывал, а только перевёл.

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

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

>Напомню вам ваши же слова:
Вообще-то они не мои… вы перепутали. Ну да ладно.

>а только перевёл.
Ну я это заметил.

Повторю в двух словах: у автора (да, перевод, не вопрос, но общаемся же мы с вами, а не с ним) нет требования, чтобы hello обрабатывала ошибки. Если есть — можете показать, где оно написано? В итоге, нет определения того, что есть успех. Тот факт, что автор (и возможно вы с ним за компанию) считаете, что успехом является вывод Hello, world куда-то, на самом деле не сформулирован. Поэтому скажем я вполне могу считать успехом то, что программа всегда возвращает 0. И чем мой успех хуже вашего, если требования на бумажке не записаны?

Действительно, перепутал. Без аватарок сложно ориентироваться.

Есть определение hello world, как программы выводящей соответствующий текст. Есть требование к программам возвращать не 0, если выполнение неуспешно. Ни одно из условий не выполнено. Лично у меня язык не поворачивается назвать это не багом. Т.е. баг есть. Об этом автор, вроде как, и пишет.

Так где оно, определение? Собственно, у меня претензия к автору именно в этом — что в наличии есть лишь примеры кода, которые формально спецификацией не являются. Без формального определения — не о чем говорить.

>Есть требование к программам возвращать не 0, если выполнение неуспешно.
Я думаю, что нет такого требования. Это это называется соглашение. И следовать ему никто не обязан, строго говоря.

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

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

>Ни одно из условий не выполнено.
Весь вопрос в том, что считать успехом. Ну вот представьте себе, что вы выводите этот текст на диск. Достаточно ли проверить код возврата API, или нужно убедиться, что текст сохранен (и тут уже начинается, негибкость API, кеши нескольких уровней, энергонезависимая память, пятое-десятое)? А если вы текст отдали функции API, а потом выключилось электричество, и он не сохранился — это баг? А чей, ваш, или скажем линукса/драйвера диска/файловой системы/микропрограммы где-то в потрохах SSD?

это называется соглашение

Именно так. Если в геттерах/сеттерах творить какую-то дичь, но не get/set, то это говнокод. Ничто не мешает, конечно, упереться в то, что спецификации нет и вообще как угодно методы называть можно, только зачем?

Достаточно ли проверить код возврата API

Достаточно. На то оно и API.

А если вы текст отдали функции API, а потом выключилось электричество, и он не сохранился — это баг?

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

Тогда уже не так:

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

int main(void)
{
  return puts("Hello World!");
}

А так:

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

int main(void)
{
  return puts("Hello World!") != EOF ? EXIT_SUCCESS : EXIT_FAILURE;
}

Конечно. Просто суть была в том, чтобы показать что коды возврата разные.

Программа положила вывод в stdout? Положила.

Не положила. Интерфейс "положить в stdout"

man printf:

   If an output error is encountered, a negative value is returned.

Игнорировать ошибки программа может, но это деяние, которое может быть ошибочным.

Решил посмотреть, часто ли програмисты проверяют, что им вернул printf.

Внутри busybox насчитал 2720 строк с [f]printf. Проверяется return value аж в 4 местах. Ушол за валерьянкой.

В какой версии вы проверяли С++?) Если не хватит памяти std::cout, то вылетит исключение и будет другой код возврата.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории