3932 2004-04-07 13:27:30 +0400 i386-mingw32msvc-gcc-g77 ошибка при чтении под управлением списка из файла, содержащего LF-CR конец строки 2005-07-13 15:45:59 +0400 1 1 4 Development Sisyphus i386-mingw32msvc-gcc-g77 unstable all Linux CLOSED NOTABUG http://imech.anrb.ru/~Const/mingw-g77.tar.bz2 P2 normal --- 1 const raorn lav sin qa-sisyphus oldest_to_newest 12694 0 const 2004-04-07 13:27:30 +0400 При чтении из файла под управлением списка [ read (1,*) ] может происходить ошибка, если строка завершается в DOS-формате (LF-CR). Как известно, fortran-77 при недостатке в текущей строке значения для всех параметров операторов read и print переходит к следующей строке. Однако, если строки оформлены в DOS-формате (LF-CR), символ LF (по-видимому) воспринимается как текстовый символ и при чтении числовых значений (см.пример) происходит ошибка чтения. Понятно, что в DOS (на что и ориентирован mingw кросс-компилятор) все строки оканчиваются на LF-CR Steps to Reproduce: 1. Открыть архив из примера 2. Скомпилировать lfcr.f в исполняемый файл 3. Запустить. файл CR читается нормально, файл LFCR -- с ошибкой 12729 1 raorn 2004-04-09 16:35:18 +0400 Непонятки (комментарии мои): 16:04 <raorn> Const: рассказывай что там у тебя происходит 16:07 <Const> raorn: погоди, сейчас закончу тест доступными компайлерами 16:22 <Const> raorn: Compaq Visual Fortran 6.5 (win) 16:22 <Const> <CR>: 1.20000000000000 2.30000000000000 16:22 <Const> <LF><CR>: 1.20000000000000 2.30000000000000 логично 16:22 <Const> Lahey fortran95 (lin) 16:22 <Const> <CR>: 1.200000000000000 2.300000000000000 логично 16:22 <Const> GNU g77 (lin) 16:22 <Const> <CR>: 1.2 2.3 логично 16:22 <Const> Compaq Fortran 1.2.0 (lin,alpha) 16:22 <Const> <CR>: 1.20000000000000 2.30000000000000 16:22 <Const> <LF><CR>: 1.20000000000000 2.30000000000000 странно 16:22 <Const> Intel(R) Fortran 32-bit 8.0 (lin) 16:22 <Const> <CR>: 1.20000000000000 2.30000000000000 16:22 <Const> <LF><CR>: 1.20000000000000 2.30000000000000 странно 16:22 <Const> i386-mingw32msvc-g77 (win) 16:22 <Const> <CR>: 1.2 2.3 16:22 <Const> <LF><CR>: 1.2 2.3 логично-странно - именно по поводу этого и висит баг 16:22 <Const> вот такая вот картинка 16:25 <raorn> Const: так в итоге - кросс работает? 16:26 <Const> raorn: вот этого-то я и не понял! сечас -- работает! 16:26 <raorn> Const: сборка та же самая, -alt2? 16:26 <Const> raorn: да 16:26 <raorn> Const: хм... Что по этому поводу говорит стандарт? 12730 2 const 2004-04-09 16:41:15 +0400 Стандарт ничего не говорит о способах перехода на новую строку. Только о том, что чтение должно продолжаться с новой строки. IMHO, программа, собранная любым компилятором, должна обрабатывать любой вариант перехода к новой строке, включая МАС-вский. Кстати, я добавил в тест проверку третьего варианта -- проверку не прошёлни один компайлер. 12731 3 raorn 2004-04-09 16:50:04 +0400 "Переход к новй строке" зависит от системы и прозрачен для приложения при использовании "текстового" режима открытия файла. Никто не обязан обрабатывать "досовские" концы строк под *nix или Mac, под win32 - должно обрабатываться, опять же при использовании "текстового режима". http://docs.sun.com/source/817-5066/2_io.html говорит, что "бинарный режим" принудительно включается при использовании FORM='BINARY' или FORM='UNFORMATTED'. Но главный вопрос - почему i386-mingw32msvc-g77 работает "иногда"? 12732 4 const 2004-04-09 16:59:15 +0400 > http://docs.sun.com/source/817-5066/2_io.html говорит, что "бинарный режим" > принудительно включается при использовании FORM='BINARY' или FORM='UNFORMATTED'. Это их самодеятельность. В стандарте есть только FORM='FORMATTED' и FORM='UNFORMATTED'. Первое предусмотрено в первую голову для файлов прямого доступа (двоичных). Второе -- для файлов последовательного доступа (в том числе и текстовых) и включается по умолчанию. Обрабатывать чужие концы строк оно все-таки должно. А ежели я работаю удалённо? Готовлю исходный файл, к примеру, на МАСе, а пущаю бинарь на мэйнфреёме под Юниксом? Ситуация очень даже распространённая. Пиво бы отдал за объяснение: в каком случае mingw работает неправильно, и почему ;) 12734 5 raorn 2004-04-09 17:21:10 +0400 Сильно сомневаюсь, что должно... 14018 6 const 2004-05-22 14:02:15 +0400 повторить не сумел... снимаю багу.