Открытие файла в режиме «а+»

Если файл открывается с помощью следующей команды:

FILE *f1=fopen("test.dat","a+");

Страница руководства гласит:

a+

Открыть для чтения и добавления (запись в конец файла). Файл создается, если он не существует. Исходная позиция файла для чтения находится в начале файла, но вывод всегда добавляется в конец файла.

Итак, f1 имеет 2 отдельных указателя смещения, один для чтения, а другой для записи?


c file-io file fopen file-pointer
person Community    schedule 05.09.2010    source источник

Ответы (3)


arrow_upward
19
arrow_downward

No.

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

person codaddict    schedule 05.09.2010
comment
Также может быть полезно знать, что это обычно реализуется в терминах «открыть» с флагом O_APPEND в системах POSIX: pubs.opengroup.org/onlinepubs/7908799/xsh/open.html - person Daira Hopwood; 25.07.2013
comment
В случае, если fseek не вызывается перед чтением, в приведенном ниже коде печатается много пробелов. Я ожидал, что ничего не будет напечатано на экране. Но по какой причине пробелы печатаются? Это означает, что EOF встречается неправильно. Если я раскомментирую fseek ниже, данные будут правильно напечатаны на экране. int main() { FILE *fp1; char ch; fp1=fopen("m.txt", "a+"); fputs("data appended", fp1); //fseek(fp1,0,SEEK_SET); while((ch=getc(fp1))!=EOF) { putc(ch,stdout); } fclose(fp1); return 0; } - person Jon Wheelock; 07.06.2016

arrow_upward
4
arrow_downward

Нет, у него только один указатель.

person raj_arni    schedule 05.09.2010

arrow_upward
4
arrow_downward

Вы не можете никогда смешивать операции чтения и записи в FILE без вызова fseek между ними. В некоторых реализациях он может работать так, как вы хотите, но программа, зависящая от этого, имеет неопределенное поведение. Таким образом вопросы наличия 2 позиции бессмысленны.

person R.. GitHub STOP HELPING ICE    schedule 05.09.2010
comment
Истинный. Однако, если вы когда-либо видели реализацию операционной системы на C, которая поддерживает операции с файлами POSIX и где операции stdio FILE представляют собой нечто иное, чем тонкий слой буферизации над операциями POSIX (которые do определили поведение в этом case), пожалуйста, сообщите об этом как об ошибке в этой ОС. - person Daira Hopwood; 25.07.2013
comment
@DairaHopwood: я не понимаю, что ты пытаешься сказать. Проблема смешивания чтения и записи на stdio без промежуточного поиска является чисто проблемой буферизации. Это не имеет ничего общего с базовыми операциями над файловыми дескрипторами. - person R.. GitHub STOP HELPING ICE; 25.07.2013
comment
Я имею в виду, что я считаю реализацию stdio глючной, если ее неопределенное поведение в этом случае приводит к чему-либо, кроме изменения того, куда, если вообще, записываются буферизованные данные. То есть спецификация должна была заключаться в том, что результирующее содержимое файла определяется реализацией, а не действительно неопределенным поведением. В противном случае вы обнаружите, что множество программ содержат ошибки безопасности, которые можно использовать. - person Daira Hopwood; 26.07.2013
comment
Нет, не глючит. Например, одна очень хорошая реализация будет выполнять __asm__("hlt"); или подобное, если вызывающая сторона нарушает эту часть контракта интерфейса. Однако даже если он затирал память, это все равно не ошибка. Ошибка в приложении, которое вызывает UB. - person R.. GitHub STOP HELPING ICE; 26.07.2013