Bug 3932 - i386-mingw32msvc-gcc-g77 ошибка при чтении под управлением списка из файла, содержащего LF-CR конец строки
: i386-mingw32msvc-gcc-g77 ошибка при чтении под управлением списка из файла, с...
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/i386-mingw32msvc-gcc-g77)
: unstable
: all Linux
: P2 normal
Assigned To:
:
: http://imech.anrb.ru/~Const/mingw-g77...
:
:
:
  Show dependency tree
 
Reported: 2004-04-07 13:27 by
Modified: 2005-07-13 15:45 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-04-07 13:27:30
При чтении из файла под управлением списка [ 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 -- с ошибкой
------- Comment #1 From 2004-04-09 16:35:18 -------
Непонятки (комментарии мои):

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: хм...

Что по этому поводу говорит стандарт?
------- Comment #2 From 2004-04-09 16:41:15 -------
Стандарт ничего не говорит о способах перехода на новую строку. Только о том,
что чтение должно продолжаться с новой строки. IMHO, программа, собранная любым
компилятором, должна обрабатывать любой вариант перехода к новой строке,
включая
МАС-вский. Кстати, я добавил в тест проверку третьего варианта -- проверку не
прошёлни один компайлер.
------- Comment #3 From 2004-04-09 16:50:04 -------
"Переход к новй строке" зависит от системы и прозрачен для приложения при
использовании "текстового" режима открытия файла. Никто не обязан обрабатывать
"досовские" концы строк под *nix или Mac, под win32 - должно обрабатываться,
опять же при использовании "текстового режима".

http://docs.sun.com/source/817-5066/2_io.html говорит, что "бинарный режим"
принудительно включается при использовании FORM='BINARY' или
FORM='UNFORMATTED'.

Но главный вопрос - почему i386-mingw32msvc-g77 работает "иногда"?
------- Comment #4 From 2004-04-09 16:59:15 -------
> http://docs.sun.com/source/817-5066/2_io.html говорит, что "бинарный режим"
> принудительно включается при использовании FORM='BINARY' или FORM='UNFORMATTED'.

Это их самодеятельность. В стандарте есть только FORM='FORMATTED' и
FORM='UNFORMATTED'. Первое предусмотрено в первую голову для файлов прямого
доступа (двоичных). Второе -- для файлов последовательного доступа (в том числе
и текстовых) и включается по умолчанию.

Обрабатывать чужие концы строк оно все-таки должно. А ежели я работаю удалённо?
Готовлю исходный файл, к примеру, на МАСе, а пущаю бинарь на мэйнфреёме под
Юниксом? Ситуация очень даже распространённая.

Пиво бы отдал за объяснение: в каком случае mingw работает неправильно, и
почему ;)
------- Comment #5 From 2004-04-09 17:21:10 -------
Сильно сомневаюсь, что должно...
------- Comment #6 From 2004-05-22 14:02:15 -------
повторить не сумел...

снимаю багу.