Truncated line as an error

How to set that specific type of error and only it -- when the line is truncated -- is considered as compilation error? That's the type of errors from the hell. That will also probably require that FTN95 do a bit better job to define what is truncated line and what is not (we discussed that a while ago), but this is really needed

Your question is rather vague. Can you give an example?

As you know the line length is restricted by the Fortran Standard and depends on whether you are using fixed or free format. So errors can occur if the permitted line length is exceeded.

I would be nice if you could reply in a manner that does not appear to be abusive.

Sorry, if my post seems this way, i'm not a pro in English, i do not feel it because permanently translate into another one and back which goes too slow. 😃 I usually edit my post 10-20 times before stop exhausted. This time i was looking for the error in the someones code the whole night and seems what you see as abusive is just first 5th or 8th edition. I do not want anyone to read my first ones even though they would be considered as top of politeness in my motherland language LOL (i will reserve that to someone who took the decision not to make FTN95 64bit capable ). Anyway there was nothing personal

Here is an example in fixed format (please make sure tab is used a as first symbol)

	a0123456789=1
	b0123456789=1
	c0123456789=1
	d0123456789=1

	write(*,*)a0123456789,a0123456789,b0123456789,c0123456789           !this is just the comment
	write(*,*)a0123456789,a0123456789,b0123456789,c0123456789,d0123456789
	end

First, compiler incorrectly says about number of truncated lines considering first long one as a truncated

Second, it correctly warns about next line which is indeed truncated, but this message will be left unnoticed in the million line codes.

There exist way to help a bit with such errors by using IMPLICIT NONE but that's not very useful option in large legacy codes which will require too much work

So my request was to fix first one and to allow making real truncated lines as errors. There also exist an option to consider all warnings as error but again in a million line codes that is not usable, all such codes have millions of warnings

Dan,

You can use /WIDE_SOURCE to remove the column 72 limit in what would otherwise be fixd format. Even if you don't want to look at every warning, you could test compile [u:750053222f]with[/u:750053222f] /WIDE_SOURCE and [u:750053222f]without[/u:750053222f] it and compare the final totals of warnings.

Perhaps with your first truncation you are asking for a warning NOT to be issued if the truncation occurs in an in-line comment. I can see the point of that, as it makes no difference to the code generated.

Eddie

Eddie, /WIDE_SOURCE is invitation to disaster of another sort. I use 132 char source too and permanently cross the limit. Still, the text width must have a limit. And my strong feeling is that compiler must consider this specific warning as an error. IT IS 100% error. Or you suggest not to have any limits at all? That could be error prone suggestion from the other end because in this case you typically do not see the whole text. That kind of text styles are common with HTML/Java to cause vomit respond and keep away the copycats LOL. No, with all my extremism, after trying that i'd never want the /WIDE_SOURCE for myself

Just to clarify, exceeding the line limit is treated as an error unless /WIDE_SOURCE is use and the warning tells the user they should look again at the line.

Paul,

1. Compiling above program gives me no error without /wide_source, only warnings

2. Similarly compiling without /wide_source this slightly modified program (again, will stress that because taking the code from this forum as is adds me one more space - are your results different?) where tab is 8 spaces and comments are placed into 73 position gives me 4(!) warnings about truncated lines. Please check

        a0123456789=1
        b0123456789=1
        c0123456789=1
        d0123456789=1
   
        write(*,*)a0123456789,a0123456789,b0123456789,c0123456789       !,d0123456789
        write(*,*)a0123456789,a0123456789,b0123456789,c0123456789       d0123456789
   
        end
   

3. More disastrous consequences of not treating truncation as an error i is demonstrated here.

        a0123456789=1
        b0123456789=1
        c0123456789=1
        d0123456789=1
        e0123456789=1
   
        write(*,*)a0123456789,a0123456789,b0123456789,c0123456789,d0123456789,
     *  e0123456789
   
        end
   

The compilation diagnostics is here

0004)         d0123456789=1
WARNING - Variable D0123456789 has been given a value but never used
0005)         e0123456789=1
WARNING - Variable E0123456789 has been given a value but never used
0007)         write(*,*)a0123456789,a0123456789,b0123456789,c0123456789,d0123456789,
0008)      *  e0123456789
WARNING - Variable D01234E0123456789 has been used without being given an 
    initial value
    NO ERRORS, 3 WARNINGS  [<main program> FTN95/Win32 v6.30.0]
0010)         end
WARNING - There are (at least) 2 truncated line(s) in this file
Creating executable: ccc2.EXE

First, the exe file was created, instead of failing. Then wrong amount of truncated lines was reported. And third, compiler should be more clever in determining that user clearly made an error hitting the line borders and report that as an error because anyone from the first glance will tell that programmer's intention was to print variables d0123456789 and e0123456789, not truncated and combined into one new variable d01234e0123456789

Things are that in large legacy codes you will get hundreds of kilobytes of comments and warnings (just checked one atomic code - 304K, 6213 lines of warnings, another hydrocode 439K of comments/warnings !) and will never find such errors. Allowing /wide_source will brake discipline of programmer and he will gradually use larger and larger lines which will make sources not fit into the screens and be eventually unmanageable. Usage of 72/132 character limit will still be most common for next many decades and all will go over the fence unintentionally all the way. With this specific error compiler easily can determine programmer's intention and tell if error was made.

I understand that other compilers do not do even that and appreciate that FTN95 is a true champ in pest control but this specific improvement if implemented will make it even better. For large codes allowing the key when warning is treated as an error is of critical importance.

You can upgrade this warning to an error by creating a local ftn95.cfg file that contains the line

/message_set_to_Error 61

If you put this file next to ftn95.exe then the upgrade will be applied to every call to ftn95.exe. Otherwise it just applies to calls from the local folder.

The usual way to create this file is by issuing the command

ftn95 /config

but this can get a little tricky at times.

A Fortran 77 compiler (and a Fortran 90, 95 compiler) is allowed to ignore anything after column 72 and it doesn't need to give even a warning or an error. These lines were traditionally used for 'sequence' numbers so that Fortran codes on card decks could be put in the correct order after they have been dropped on the lab floor.

It is perfectly reasonable for FTN95 to issue just a warning for these lines. But you can change the warning to an error if you want.

Alternatively, it is a relatively easy task to find such lines before you compile the code. You can write a Fortran program to find and print them out. Or you can find them in a decent editor such as vi.

Paul, Glad that there exist such possibility. Tried /message_set_to_Error 61 but it does not go by some reason. Error report is

*** /MESSAGE_SET_TO_ERROR is not a valid option in a /OPTIONS file, FTN95.CFG, C:\Program Files (x86)\Silverfrost\FTN95\FTN95.CFG or the environment variable FTN95CFG - use FTN95 /? for valid options

Second option also does show hot to turn this warning into error. Can you please look again?

Davidb, I'd better use punchcards then VI editor! Which means i am not a true programmer LOL Yes, i have written such program years ago and use it sometimes ones a year. It is part of the code so the code checks itself (and is doing some other useful stuff). This helped to find few violations. But it is not convenient for everyday use, the compiler must do that job.

'/MESSAGE_SET_TO_ERROR 61' is not a command line option.

It must go into a ftn95.cfg file or (I guess) another /OPTIONS file.

Quoted from DanRRight

I'd better use punchcards then VI editor! Which means i am not a true programmer LOL

Forget Vi, real programmers use ISPF! 😄

There is a really nice ISPF-style editor available called SPFLite. You could just type the following as primary commands:

X ALL
F ALL 73 P'='

What it does? The first command excludes all lines from the display. Second command uses picture format string to find and show all lines that have some character on column 73.

May not look too sexy, but is quite informative

Paul, I dunno, something is wrong. I tried all variants and then some, but none goes. Can anybody try too and then compile the above snippets and get an error instead of warning?

Jali I like NoteTab,use it from its start 15+ years ago, it got a lot of all kinds of awards as best editor. But editor or compiler people use are religious questions, so i do not push it. (Its icon by the way was made on Salford Icon Editor 😃

Paul,

I agree with Dan. I installed the option for 61 to be an error, using FTN95 /config in a local ftn95.cfg file. This resulted in the following .cfg file: /ERROR_NUMBERS /message_set_to_Error 61

When used, I got the following error: [FTN95/Win32 Ver. 6.30.0 Copyright (c) Silverfrost Ltd 1993-2012]

*** Error 2: /MESSAGE_SET_TO_ERROR is not a valid option in a /OPTIONS file, 
    FTN95.CFG, C:\\Program Files (x86)\\Silverfrost\\FTN95\\FTN95.CFG or the 
    environment variable FTN95CFG - use FTN95 /? for valid options

John

Sorry about that. I will check it out.

It turns out that the code for this particular option was missing. The other /SET_MESSAGE_TO_ options appear to work. They can, in fact, be issued directly from the command line without using an options file.

I can fix this but maybe not in time for the next release.

This bug has now been fixed for the next release.

Thanks, Paul. Please consider making that warning an error by default, i bet almost everyone here with large codes (specifically written by someone else) have truncation errors and even do not know about that. I fixed not less then 100 of truncations last year just in one single third-party code (it was written for non-FTN95 compiler, the FTN95 would find that easily with /undef but again, not everyone use or even know that. Even i myself despite of being fan of /undef and even claiming that your code is definitely wrong until it passed /undef, tend to avoid it to the last point when nothing go because it is so really truly abusive by telling me straight into the face how many dumbest mistakes i make LOL )

Also, i have to stress again the point shown above, i do not know if you have missed it or not, that for anything placed into 73d position, even the exclamation mark, compiler issues truncation warning. The most interesting is that exclamation mark in 72d position gives no warning, in 74th position gives no warning but in 73d it warns. 😃

That will become a real issue after this bug fix. There are a lot of comments in the codes starting with 73d position, like mentioned above ancient punchcard indexing to modern codes where people use exclamation mark in 73d position because it is next after tab. If i will have time i will run the filter to find how many such comments in the codes i use but bet the number is in hundreds

Thanks. I will log the problem about the exclamation mark in column 73.

Just wrote separate small code which counts exclamation marks in 73d position

  integer*2  maxNumbFiles_InDir, NumbFiles_InDir, Error_codeDb
  parameter (maxNumbFiles_InDir = 8000)
  character*128 FILES_InDir(maxNumbFiles_InDir)
  integer*2 ATTR_files(maxNumbFiles_InDir),date_files(maxNumbFiles_InDir), time_files(maxNumbFiles_InDir)
  integer file_size(maxNumbFiles_InDir)
  character  textsample*128, text256*256
  

   textsample= '*.f*'
   FILES_InDir(:)=' '

    call files@ (textsample, NumbFiles_InDir, maxNumbFiles_InDir, FILES_InDir, ATTR_files, date_files, time_files, file_size)
    print*, 'NumbFiles_InDir=',NumbFiles_InDir
!   print*, FILES_InDir

   iExclCount = 0
   nLinesOfFortranCode = 0
   do i=1, NumbFiles_InDir
      open (111,file=FILES_InDir(i), err=994, status='old' ) 

      do j=1,1000000
        read (111,'(a)',err=995,end=3333) text256 
        nLinesOfFortranCode =  nLinesOfFortranCode + 1
        if(text256(73:73).eq.char(33)) then
        iExclCount = iExclCount + 1
        endif
      enddo 


3333  continue
      enddo

   print*, 'Total lines of Fortran code=', nLinesOfFortranCode
   print*, 'Number of exclamation marks in 73d position=', iExclCount


   goto 1000
 
994 print*, ' can not open file=',FILES_InDir(i)
   goto 1000
995 print*, ' Error reading the file=',FILES_InDir(i)
   goto 1000

1000	continue
end

and got

NumbFiles_InDir= 189 Total lines of Fortran code= 1611952 Number of exclamation marks in 73d position= 1342

So this issue if not fixed will be truly killing us! Please look at it and resolve it in the same release!

You can modify the code to count anything starting with 73 position since it will give an error too. Or to give the same stats for 133 position. What is your statistics ?

( You can also check how many Clearwin+ % codes have been used in your program -- %=char (37) -- or how many thousand times you wrote keyword winio@ LOL. Another modification of this program gives you information if your code has error by hitting beyond 72 positions etc. All that is implemented in our larger code)