Сначала код:

Открываются два бинарных файла - один для чтения, другой для записи. Происходит побайтовое копирование из одного в другой. Если то же самое производить для текстовых файлов (заменить параметр rb и wb на rt и wt), то может не правильно определяться конец файла. Я рассматривал этот пример на файле в 295Кб, а результатом для текстового режима оказался только файл в 5Кб. Это первый вопрос: как для текстового режима определить конец файла?
Следующие заморочки наступают, когда один файл указан как текстовый, а другой как бинарный. Допустим, что считываем с бинарного файла, а пишем в текстовый. Тогда из бинарного файла все символы '\n' заменятся на текстовые '\r\n' - я так понимаю? т.к. судя по мои опытам - размер файлика увеличивается. Второй вопрос: что еще может преобразовываться, помимо сивола конца строки '\n'? И будут ли преобразования, если считывать из бинарного файла, а писать в текстовый? (этот случай не могу проверить из-за неправильного определения конца файла).

В коде можно заметить, что считываемый символ (s) объявлен как целое число - я вычитал, что конец файла может определяться, как (-1), что недопустимо при типе char. Судя по документации - некоторые функции из stdio сравнивают позицию курсора и длину файла. Какие именно?

froex, Надо так:


Добавлено через 32 секунды
Но нужно блоками копировать.

Добавлено через 2 минуты и 1 секунду
Мне никогда не приходило в голову читать бинарный файл этими функциями. 

Добавлено через 5 минут и 16 секунд
У тебя такое кол-во вопросов, только из-за того, что эти функции для этого не предназначены!
Попробуй написать свою версию. Вдруг так проще.

Для текстового режима не работает. Конец файла определяется неправильно.

Странно  
У меня работает. Все правильно определяется.

Ты небось на скорую руку сам файлик напечатал. У меня же вместо такого вот текста берется сохраненный дамп памяти открытой программы - там могут быть какие угодно символы.

froex, Ты не понимаешь о чем говоришь.

Если ты не в теме - то чего говоришь? Я изначально сказал, что проблема для текстового режима. Для файла как для бинарного все отлично срабатывает. При считывании как текстового - конец файла наступает почти в самом начале. Я не знаю почему.

Выкладываю обрабатываемый файл. Моя прога выдает только 5Кб от этого файла. Если обрабатывать как бинарный файл, то проблем нет.

Это сообщение отредактировал(а) froex - 2.7.2009, 20:14

Присоединённый файл ( Кол-во скачиваний: 5 )
 input.dmp 292,00 Kb

froex так он собственно содержит символы, которые не принадлежат допустимому алфавиту для текстовых файлов, вот оно и останавливается. Ctrl+Z вроде бы "конец файла"...
А чем плохо бинарное общение с файлом?

Ничего плохого нет. Просто я хочу узнать, есть ли решения для текстовых файлов поиска истинного конца файла.

Текстовый файл - это файл, не содержищий "нетекстовых" символов, а вовсе не открытый в текстовом режиме. Ты же хочешь узнать, можно ли нетекстовый файл читать как текст. Нельзя.

Earnest, Как я ни пытался вдолбить это, в пустую.

Добавлено через 2 минуты и 28 секунд

Для любого файла, концом файла является тот момент, когда позиция чтения равняется размеру файла.

Добавлено через 6 минут и 23 секунды
А определение конца файла по какому-то символу, не верно!

я раньше конец текстового файла определял с помощью символа '\032'. но мне это решение никогда не нравилось...
сейчас перешёл на istream_iterator! 

Что это за техника подсчета символов в файле? Перебрать все символы? А если файл метро 200 будет? 

Получай размер файла и всё.....

сейчас видео-файлы и по 50 гиг есть  blue-ray