Как индикатор ошибки потока влияет на следующий код ввода?

Все, что вы говорите, кажется правильным, и ch==EOF && !feof(f) - это правильный способ проверить наличие новых ошибок, не мешая накоплению ошибок.

Assuming no UB, are 5 of the 8 possible and not the 3 unexpected ones? especially is valid input possible with error indicator set?

Говоря конкретно о положениях стандарта, я склонен согласиться с вашим анализом:

• Для очистки индикатора ошибки потока указано несколько функций, и fgetc() не входит в их число.. В общем, ни одна из них не является функциями передачи данных. Следовательно, если индикатор ошибки установлен для потока до того, как этот поток будет представлен в fgetc() для чтения, он все равно должен быть установлен, когда эта функция вернется, несмотря на все другие соображения. Это касается следующих случаев: ^*

  1  0   0   Unexpected
  1  1   0   Unexpected
  1  1   1   Input error or end-of-file
  

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

  1  0   1   Normal reading of valid data with error indicator set!
  

• fgetc() указан для возврата EOF в каждой ситуации, в которой он указан для установки индикатора конца файла в потоке.. Следовательно, если fgetc() возвращает что-либо, кроме EOF, то при этом вызове он не будет устанавливать индикатор ошибки потока (или конца файла). Это касается следующих случаев:

  0  0   0   Normal reading of valid data    
  0  0   1   Unexpected
  

  С другой стороны, если fgetc()делает возвращает EOF, то впоследствии должен быть установлен либо индикатор конца файла потока, либо его индикатор ошибки. Но стандарт различает эти случаи и указывает, что пользователь может различать их с помощью функций feof() и ferror(). Это касается следующих случаев: ^*

  0  1   0   End-of-file
  0  1   1   Input error
  

• Наконец, я согласен с тем, что ни одно поведение fgetc() не зависит от начального состояния индикатора ошибки потока. При условии, что поток изначально не позиционируется в конце и его индикатор конца файла изначально не установлен, «функция fgetc возвращает следующий символ из входного потока, на который указывает поток». Это устанавливает, что это, наиболее интересный случай, на самом деле разрешено:

  1  0   1   Normal reading of valid data with error indicator set!
  

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

If codes does not clear the error indicator before hand and wants to detect if a line of input had a rare input error, it seems to make sense to test !feof() and not ferror() to detect.

Is checking ferror() potentially misleading? or have I missed something about the error indicator?

Я согласен с тем, что если изначально установлен индикатор ошибки потока, а индикатор конца файла - нет, и чтение его с помощью fgetc() возвращает EOF, тогда ferror() не проводит различий между случаями конца файла и ошибками, тогда как feof() должен.

С другой стороны, можно ли продолжать чтение данного потока после того, как в нем обнаружена ошибка, зависит от реализации и, возможно, от конкретных обстоятельств. Это применимо, даже если индикатор ошибки сброшен с помощью вызова clearerr(), не говоря уже о том, очищен ли индикатор ошибки нет.

^* Хотя я согласен с тем, что существует двусмысленность в отношении EOF в случае, если это UCHAR_MAX > INT_MAX, я утверждаю, что это лишь одна из нескольких причин, по которым такая реализация будет проблематичной. Поэтому с практической точки зрения я не считаю такие реализации полностью гипотетическими.

Вот очень грубая, очень минимальная программа для изучения поведения библиотеки GNU C по отношению к fgetc(), ferror() и feof(), как запрошено OP в комментарии:

#define  _POSIX_C_SOURCE  200809L
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <signal.h>
#include <errno.h>

static volatile sig_atomic_t  interrupted = 0;

static void interrupt_handler(int signum)
{
    interrupted = 1;
}

static int install_interrupt(const int signum)
{
    struct sigaction  act;

    memset(&act, 0, sizeof act);
    sigemptyset(&act.sa_mask);
    act.sa_handler = interrupt_handler;
    act.sa_flags = 0;
    if (sigaction(signum, &act, NULL) == -1)
        return -1;

    return 0;
}

int main(void)
{
    int  n, c;

    if (install_interrupt(SIGALRM)) {
        fprintf(stderr, "Cannot install SIGALRM handler: %s.\n", strerror(errno));
        return EXIT_FAILURE;
    }

    if (ferror(stdin)) {
        fprintf(stderr, "Standard input is already in error state.\n");
        return EXIT_FAILURE;
    }
    if (feof(stdin)) {
        fprintf(stderr, "Standard input is already in end-of-input state.\n");
        return EXIT_FAILURE;
    }

    fprintf(stderr, "Testing stream error state. Please wait.\n");

    alarm(1);
    c = fgetc(stdin);
    if (c != EOF) {
        fprintf(stderr, "Stream error state test failed.\n");
        return EXIT_FAILURE;
    }

    fprintf(stderr, "fgetc(stdin) returned EOF.\n");
    fprintf(stderr, "ferror(stdin) returns %d.\n", ferror(stdin));
    fprintf(stderr, "feof(stdin) returns %d.\n", feof(stdin));

    fprintf(stderr, "\n");
    fprintf(stderr, "Testing stream end-of-input state. Please press Ctrl+D.\n");
    c = fgetc(stdin);
    if (c != EOF) {
        fprintf(stderr, "fgetc() returned %d; EOF was expected.\n", c);
        return EXIT_FAILURE;
    }
    fprintf(stderr, "fgetc(stdin) returned EOF.\n");
    fprintf(stderr, "ferror(stdin) returns %d.\n", ferror(stdin));
    fprintf(stderr, "feof(stdin) returns %d.\n", feof(stdin));
    if (!ferror(stdin) || !feof(stdin)) {
        fprintf(stderr, "Expected error and end-of-file states; aborting.\n");
        return EXIT_FAILURE;
    }

    fprintf(stderr, "\n");
    fprintf(stderr, "Testing fgetc() when stream in error and end-of-file state.\n");
    fprintf(stderr, "Please type something, then press Enter.\n");
    n = 0;
    c = fgetc(stdin);
    while (c != EOF && c != '\n') {
        n++;
        c = fgetc(stdin);
    }
    if (c == EOF) {
        fprintf(stderr, "Further input is not possible.\n");
        return EXIT_FAILURE;
    } else
        fprintf(stderr, "Further input is possible: %d characters (including Enter) read.\n", n + 1);

    return EXIT_SUCCESS;
}

Когда я компилирую и запускаю вышеуказанное в Linux, программа выведет

Testing stream error state. Please wait.
fgetc(stdin) returned EOF.
ferror(stdin) returns 1.
feof(stdin) returns 0.

Состояние ошибки было вызвано прерыванием доставки сигнала при вызове fgetc(stdin). Как видите, ferror(stdin) действительно возвращает ненулевое значение. Обратите внимание, что feof(stdin) возвращает 0.

Вывод продолжается:

Testing stream end-of-input state. Please press Ctrl+D.

Нажатие Ctrl + C дает результат

fgetc(stdin) returned EOF.
ferror(stdin) returns 1.
feof(stdin) returns 1.

На этом этапе стандартный ввод находится как в состоянии ошибки, так и в состоянии конца файла. Вывод продолжается:

Testing fgetc() when stream in error and end-of-file state.
Please type something, then press Enter.

Если теперь ввести, скажем, OKEnter, мы получим

Further input is possible: 3 characters (including Enter) read.

Это доказывает, что по крайней мере реализация библиотеки GNU C вообще не проверяет ошибку потока или состояние конца файла. Он просто попытается прочитать больше данных (используя базовую операцию read() в системах POSIXy).

Я так понимаю стандарт, что он явно не говорит, что fgetc разрешено возвращать значение, отличное от EOF, если индикатор ошибки уже был установлен в потоке при входе, но он также не говорит явно, что это не могу. Я сочувствую наблюдению Nominal Animal (которое я извлечу из комментариев к его ответу на случай, если он будет удален или перемещен в чат; позвольте мне на мгновение потрогать свой личный топор и заметить, что политика обработки комментариев как "эфемерных" вредна и должны быть отменены):

IMHO the standard is then bass-ackwards: there is no practical need for EOF to be sticky, but if error is not sticky, then there is a real risk of accidentally missing errors.

Однако, если все существующие реализации последовательно не рассматривают ошибку как постоянную, изменить поведение будет очень сложно продать комитету. Поэтому прошу у сообщества тесты:

Ниже представлена ​​сокращенная неинтерактивная версия Программа испытаний номинального животного. Он смотрит только на поведение fgetc после ошибки чтения, но не на EOF. Он использует SIGALRM для прерывания чтения вместо Ctrl-C, поэтому вам не нужно ничего делать, кроме как запустить его.

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

static _Noreturn void
perror_exit (const char *msg)
{
  perror (msg);
  exit (1);
}

static void
handler (int unused)
{
}

int
main (void)
{
  struct sigaction sa;
  int pipefd[2];
  FILE *fp;
  int ch, pa;

  setvbuf (stdout, 0, _IOLBF, 0);

  sa.sa_handler = handler;
  sa.sa_flags = 0; /* DO interrupt blocking system calls */
  sigemptyset (&sa.sa_mask);
  if (sigaction (SIGALRM, &sa, 0))
    perror_exit ("sigaction");

  if (pipe (pipefd))
    perror_exit ("pipe");

  fp = fdopen (pipefd[0], "r");
  if (!fp)
    perror_exit ("fdopen");

  printf ("before fgetc 1, feof = %d ferror = %d\n",
          feof (fp), ferror (fp));

  alarm (1);
  ch = fgetc (fp);

  if (ch == EOF)
    printf ("after fgetc 1, ch = EOF feof = %d ferror = %d\n",
            feof (fp), ferror (fp));
  else
    printf ("after fgetc 1, ch = '%c' feof = %d ferror = %d\n",
            ch, feof (fp), ferror (fp));

  write (pipefd[1], "x", 1);
  alarm (1);
  ch = fgetc (fp);
  pa = alarm (0);

  printf ("after fgetc 2, alarm %s\n",
          pa ? "did not fire" : "fired");

  if (ch == EOF)
    printf ("after fgetc 2, ch = EOF feof = %d ferror = %d\n",
            feof (fp), ferror (fp));
  else
    printf ("after fgetc 2, ch = '%c' feof = %d ferror = %d\n",
            ch, feof (fp), ferror (fp));

  return 0;
}

На всех Unix, которые я могу получить на данный момент, результат этой программы согласуется с наблюдением Джона Боллинджера о том, что

the case of most interest, is in fact allowed:

1  0   1   Normal reading of valid data with error indicator set!

Я особенно хотел бы знать, что эта программа печатает при запуске в альтернативных библиотеках C на базе Linux (например, musl, bionic); Unix-системы, которые не относятся к Linux и не относятся к типу BSD; и Windows. Если у вас есть что-то еще более экзотическое, попробуйте и это. Я отмечаю это сообщение вики сообщества; пожалуйста, отредактируйте его, чтобы добавить результаты теста.

Программа тестирования должна быть приемлемой для любого C89-совместимого компилятора для среды, в которой существует unistd.h, а signal.h определяет sigaction, за исключением одного использования ключевого слова C11 _Noreturn, которое предназначено только для подавления предупреждений. Если ваш компилятор жалуется на _Noreturn, скомпилируйте с -D_Noreturn=; на результаты это не повлияет. Если у вас нет unistd.h, тестовая программа не сделает ничего значимого в вашей среде. Если у вас нет sigaction, вы мая сможете адаптировать программу для использования альтернативных интерфейсов, но вам нужно убедить SIGALRM как-то прервать блокирующий read.

Полученные результаты

before fgetc 1, feof = 0 ferror = 0
after fgetc 1, ch = EOF feof = 0 ferror = 1
after fgetc 2, alarm did not fire
after fgetc 2, ch = 'x' feof = 0 ferror = 1

(«нормальное чтение достоверных данных с установленным индикатором ошибки»)

• Linux с glibc 2.27
• NetBSD 7.1.2
• FreeBSD 11.2-РЕЛИЗ-p4
• macOS 10.14, clang-1000.10.44.2
• macOS 10.14, gcc 8.2.0 (доморощенный)

.

before fgetc 1, feof = 0 ferror = 0
after fgetc 1, ch = EOF feof = 0 ferror = 1
after fgetc 2, alarm did not fire
after fgetc 2, ch = EOF feof = 0 ferror = 1

(Поведение «липкая ошибка»: fgetc(fp) немедленно возвращает EOF без вызова read, если ferror(fp) истинен при входе)

• Plan 9 (компилятор не распознает _Noreturn)

.