Шестнацатеричные константы в фортране

[Alex-Yu]

Понадобилось мне откомпилировать программу на фортране (не мою). Взял я gfortran под linux.... И начались чудеса. Вообще-то я фортран уже напрочь забыл (ну, паскаль еще помню кое как). Но вроде конструкция

DATA TAB/X'09'/

совершенно корректная. Определяется константа TAB с шестнадцатеричным значением 09 (табуляция). Длина один байт. Нет???? Компилятор ругается Error: Incompatible types in DATA statement at (1); attempted conversion of INTEGER(16) to CHARACTER(1)

В чем дело, кто подскажет? На самом деле это я исправил (да так это делается, я же помню!), в исходном тексте было

DATA TAB/z9/

Довольно странно, но в новых фортранах много всяких новостей, может так бывает тоже. Но на это компилятор ругается точно также.

Любые советы приветствуются. А то я программирование уже и совсем забыл.

[Pphantom]

Alex-Yu в сообщении #1199142 писал(а):

Понадобилось мне откомпилировать программу на фортране (не мою). Взял я gfortran под linux.... И начались чудеса. Вообще-то я фортран уже напрочь забыл (ну, паскаль еще помню кое как). Но вроде конструкция

DATA TAB/X'09'/

совершенно корректная. Определяется константа TAB с шестнадцатеричным значением 09 (табуляция). Длина один байт. Нет???? Компилятор ругается Error: Incompatible types in DATA statement at (1); attempted conversion of INTEGER(16) to CHARACTER(1)

Приведите минимальный код, который теоретически можно скомпилировать, но не удается. Просто так ошибка не воспроизводится, имеющиеся под руками gfortran'ы (4.8.5, 5.3.1, 6.2.1) обрабатывают эту строчку корректно.

[Alex-Yu]

Pphantom в сообщении #1199149 писал(а):

Alex-Yu в сообщении #1199142 писал(а):

Понадобилось мне откомпилировать программу на фортране (не мою). Взял я gfortran под linux.... И начались чудеса. Вообще-то я фортран уже напрочь забыл (ну, паскаль еще помню кое как). Но вроде конструкция

DATA TAB/X'09'/

совершенно корректная. Определяется константа TAB с шестнадцатеричным значением 09 (табуляция). Длина один байт. Нет???? Компилятор ругается Error: Incompatible types in DATA statement at (1); attempted conversion of INTEGER(16) to CHARACTER(1)

Приведите минимальный код, который теоретически можно скомпилировать, но не удается. Просто так ошибка не воспроизводится, имеющиеся под руками gfortran'ы (4.8.5, 5.3.1, 6.2.1) обрабатывают эту строчку корректно.

Вот программный модуль целиком. Честный копипаст (почему-то сдвинулось влево, на самом деле все правильно, с отступом). В других модулях тоже встречается такая конструкция и тоже не работает.

Используется синтаксис Fortran

      FUNCTION   STR_LENGTH
     &          (string)

c***********************************************************************
c                         subroutine str_length
c***********************************************************************

c  Program Source:  Naval Ocean Systems Center - Code 542

c  Date:
c     05 Apr 1990

c  Function:
c     Returns the location of the last right-most non-blank character of
c     a string.  Leading blanks are included in the length.

c  Parameters passed:
c     string           [s] character string

c  Parameters returned:

c  Common blocks referenced:

c  Functions and subroutines referenced:
c     len

c  References:

c  Change History:
c     08 May 96     Added test for TAB character.

c*******************!***************************************************

      character     string*(*)
      character*  1 TAB
      integer       str_length
      data          TAB/z'09'/


c     Check if string is defined
      if (ichar(string(1:1)) .eq. 0) then
         str_length=0
      else
c        Determine the dimension of the string
         str_length=LEN(string)
c        Count the number of characters in the string
10       if (ichar(string(str_length:str_length)) .gt. 0) then
            if (string(str_length:str_length) .ne. ' ' .and.
     &          string(str_length:str_length) .ne. TAB) RETURN
         end if
         str_length=str_length-1
         if (str_length .gt. 0) go to 10
      end if

      RETURN
      END      ! STR_LENGTH
 

[Pphantom]

Теперь понятно. Код использует "нечестное" приведение типов, которое формально запрещено (но, по-видимому, не вылавливалось старым компилятором). Замените строчку c DATA на TAB=achar(9), должно заработать.

[Karan]

Alex-Yu в сообщении #1199154 писал(а):

почему-то сдвинулось влево, на самом деле все правильно, с отступом

Используйте тэг syntax (topic26708.html). Я поправил Ваш код.

[Alex-Yu]

Подсказка, что строчка работает уже принесла пользу. Кое-что я выяснил. Вот простейший файл, который работает


C CHARACTER*1 TAB
DATA TAB/x'09'/
END

Но стоит раскомментировать первую строчку, как работать перестает. Проблема в взаимодействии этих строчек.

-- Сб мар 11, 2017 22:36:32 --

Pphantom в сообщении #1199163 писал(а):

Теперь понятно. Код использует "нечестное" приведение типов, которое формально запрещено (но, по-видимому, не вылавливалось старым компилятором). Замените строчку c DATA на TAB=achar(9), должно заработать.

ОК, попробую. Но все же лучше бы ближе к исходному коду, как бы это все победить. Может ключ какой поставить.... Такая конструкция в многих модулях присутствует, причем с вариациями, не уверен, что Ваш совет сработает и в др случаях.

-- Сб мар 11, 2017 22:43:48 --

Pphantom в сообщении #1199163 писал(а):

Теперь понятно. Код использует "нечестное" приведение типов, которое формально запрещено (но, по-видимому, не вылавливалось старым компилятором). Замените строчку c DATA на TAB=achar(9), должно заработать.

Не работает тоже.

[Pphantom]

Alex-Yu в сообщении #1199173 писал(а):

Но стоит раскомментировать первую строчку, как работать перестает. Проблема в взаимодействии этих строчек.

Именно. Сначала Вы объявляете переменную TAB как символьную, а потом запихиваете в нее целое значение. Так нельзя.

Alex-Yu в сообщении #1199173 писал(а):

ОК, попробую. Но все же лучше бы ближе к исходному коду, как бы это все победить. Может ключ какой поставить.... Такая конструкция в многих модулях присутствует, причем с вариациями, не уверен, что Ваш совет сработает и в др случаях.

Ближе не будет, какие-то исправления все равно придется вносить. По идее, если автор кода не умудрился еще каким-нибудь образом почесать левой ногой правое ухо, подобная замена должна сработать всегда и легально обеспечить то, что требуется.

-- 11.03.2017, 18:47 --

Alex-Yu в сообщении #1199173 писал(а):

Не работает тоже.

В чем это проявляется?

[Alex-Yu]

Pphantom в сообщении #1199181 писал(а):

В чем это проявляется?

Pphantom в сообщении #1199181 писал(а):

Alex-Yu в сообщении #1199173

писал(а):
Не работает тоже. В чем это проявляется?

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

Это бред какой-то! Нельзя задать символ в двоичном виде... Полны отпад. Ну ладно всякие новомодные языки (всегда я их терпеть не мог за невозможность приравнивания величин разного типа). Но фортран!!!

-- Сб мар 11, 2017 22:56:58 --

Pphantom в сообщении #1199181 писал(а):

По идее, если автор кода не умудрился еще каким-нибудь образом почесать левой ногой правое ухо

Во времена моей молодости мы запросто заносили литералы, например, в комплексные переменные. На фортране. И ни при чем здесь левое ухо. Просто компилятор не должен пытаться быть умнее программиста. Ну warning бы написал.... А то error видите ли!

[Pphantom]

Alex-Yu в сообщении #1199184 писал(а):

Пардон, это я напортачил. Но как-то это мне не нравится, хочется инициализацию на этапе компиляции, а не исполнения.

Уберите то, что было вместо DATA, полностью, а строчку объявлением переменной перепишите так:

Используется синтаксис Fortran

character(1),parameter :: TAB=achar(9)

Это тоже не совсем законно (поскольку в Fortran 77 такого не было), но у Вас и так код на 77 с расширениями, и gfortran это съест.

[Alex-Yu]

Pphantom в сообщении #1199185 писал(а):

Это тоже не совсем законно (поскольку в Fortran 77 такого не было), но у Вас и так код на 77 с расширениями, и gfortran это съест.

Я вспомнил. Совершенно законный способ: оператор equivalence (как-то не так пишется). Осталось вспомнить его синтаксис.

[Pphantom]

Alex-Yu в сообщении #1199184 писал(а):

Это бред какой-то! Нельзя задать символ в двоичном виде...

Можно. Но корректно.

Alex-Yu в сообщении #1199184 писал(а):

Полны отпад. Ну ладно всякие новомодные языки (всегда я их терпеть не мог за невозможность приравнивания величин разного типа). Но фортран!!!

Alex-Yu в сообщении #1199184 писал(а):

Во времена моей молодости мы запросто заносили литералы, например, в комплексные переменные. На фортране. И ни при чем здесь левое ухо. Просто компилятор не должен пытаться быть умнее программиста. Ну warning бы написал.... А то error видите ли!

Однако стандарт языка все равно полезно иметь в виду, даже если конкретный компилятор за ним не следит.

-- 11.03.2017, 19:07 --

Alex-Yu в сообщении #1199187 писал(а):

Я вспомнил. Совершенно законный способ: оператор equivalence (как-то не так пишется). Осталось вспомнить его синтаксис.

Не-а. EQUIVALENCE по стандарту позволяет совмещать числовые данные с числовыми, а символьные - с символьными, но не обеспечивает нужное Вам преобразование типа. Другое дело, что опять-таки во многих реализациях компиляторы это позволяли (и получался в целом непереносимый на другие платформы код).

[Alex-Yu]

Alex-Yu в сообщении #1199187 писал(а):

Я вспомнил. Совершенно законный способ: оператор equivalence (как-то не так пишется). Осталось вспомнить его синтаксис.

Вот такой код

1.  
2.            CHARACTER*1   TAB 
3.            EQUIVALENCE (TAB,INTTAB) 
4.            INTEGER*1     INTTAB 
5.            DATA    INTTAB/X'09'/    
6.            END 
7.  

компилируется успешно. И, похоже, должен правильно работать.

-- Сб мар 11, 2017 23:10:45 --

Pphantom в сообщении #1199188 писал(а):

Можно. Но корректно.

Как? Именно в операторе DATA. Решение с EQUIVALENCE я нашел, но хочется короче.

-- Сб мар 11, 2017 23:13:44 --

Pphantom в сообщении #1199188 писал(а):

Другое дело, что опять-таки во многих реализациях компиляторы это позволяли (и получался в целом непереносимый на другие платформы код).

Да, надо знать как именно размещаются данные по адресам. Но для однобайтовых величин этой проблемы, вроде, не должно быть?

[Pphantom]

Alex-Yu в сообщении #1199189 писал(а):

компилируется успешно. И, похоже, должен правильно работать.

В том смысле, что он будет давать предполагаемый результат - да. Но зачем?

Alex-Yu в сообщении #1199189 писал(а):

Как? Именно в операторе DATA. Решение с EQUIVALENCE я нашел, но хочется короче.

Именно с DATA - не знаю. Полагаю, что разумных вариантов нет, а искать неразумные не хочется.

Alex-Yu в сообщении #1199189 писал(а):

Да, надо знать как именно размещаются данные по адресам. Но для однобайтовых величин этой проблемы, вроде, не должно быть?

Да. Но проблема в том, что если в варианте, который Вы сейчас придумали, Вы перепутаете и сделаете не INTEGER*1, а, например, просто INTEGER, то это тоже отлично скомпилируется. Только вот результат будет правильным уже не всегда.

[Alex-Yu]

Pphantom в сообщении #1199195 писал(а):

Но проблема в том, что если в варианте, который Вы сейчас придумали, Вы перепутаете и сделаете не INTEGER*1, а, например, просто INTEGER

Как человек воспитанный на ассемблере, этот вариант рассматривать отказываюсь. Если программист дурак, то тут уже ничего не поможет Тогда ему в веб-дизайнеры, а не серьезными вещами заниматься (программа, с которой вожусь, весьма серьезная).

Кстати, что-то припоминаю, что вроде можно делать инициализацию прямо в декларации типа. Надо попробовать.

[Yuri Gendelman]

Фортрана под рукой нет, так что проверить сам не могу.
Допускают ли нынешние версии Фортрана C-ESC последовательности?
Например:

DATA TAB/'\t'/

В F77 это вроде бы было.