При чтении из файла под управлением списка [ 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 -- с ошибкой
Непонятки (комментарии мои): 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: хм... Что по этому поводу говорит стандарт?
Стандарт ничего не говорит о способах перехода на новую строку. Только о том, что чтение должно продолжаться с новой строки. IMHO, программа, собранная любым компилятором, должна обрабатывать любой вариант перехода к новой строке, включая МАС-вский. Кстати, я добавил в тест проверку третьего варианта -- проверку не прошёлни один компайлер.
"Переход к новй строке" зависит от системы и прозрачен для приложения при использовании "текстового" режима открытия файла. Никто не обязан обрабатывать "досовские" концы строк под *nix или Mac, под win32 - должно обрабатываться, опять же при использовании "текстового режима". http://docs.sun.com/source/817-5066/2_io.html говорит, что "бинарный режим" принудительно включается при использовании FORM='BINARY' или FORM='UNFORMATTED'. Но главный вопрос - почему i386-mingw32msvc-g77 работает "иногда"?
> http://docs.sun.com/source/817-5066/2_io.html говорит, что "бинарный режим" > принудительно включается при использовании FORM='BINARY' или FORM='UNFORMATTED'. Это их самодеятельность. В стандарте есть только FORM='FORMATTED' и FORM='UNFORMATTED'. Первое предусмотрено в первую голову для файлов прямого доступа (двоичных). Второе -- для файлов последовательного доступа (в том числе и текстовых) и включается по умолчанию. Обрабатывать чужие концы строк оно все-таки должно. А ежели я работаю удалённо? Готовлю исходный файл, к примеру, на МАСе, а пущаю бинарь на мэйнфреёме под Юниксом? Ситуация очень даже распространённая. Пиво бы отдал за объяснение: в каком случае mingw работает неправильно, и почему ;)
Сильно сомневаюсь, что должно...
повторить не сумел... снимаю багу.