No_Truncate

Why compiler with /no_truncate gives only the warning and not an error? What the sense in this case is for this key ?

WARNING - Line has been truncated (line is longer than 132 characters)

Warning like that compiler has to provide in any case with or without /no_truncate

When there is no 'implicit none', your code is large, and compiler always warns you about numerous things, you will never notice any new warnings to your 100000 old ones 😃

a1234567890=1 b1234567890=2 c1234567890=3 d1234567890=4 Write(,)'1234567890123456789012345678901234567890123456789012345678901234567890', a1234567890, b1234567890, c1234567890, d1234567890 end

Compilation C:>FTN95 zzz.f95 /link /no_truncate

/NO_TRUNCATE is for fixed format files. There was no thought that it would be useful for free format files.

John-Silver

Thank you for the feedback.

/NO_TRUNCATE provides an error report and not a warning but only for fixed format files. I will add /NO_TRUNCATE to the help documentation and update the FTN95 /? response.

The default for free format files is 132 characters and this can be extended by using /WIDE_SOURCE.

Paul, do you see any problems extending it to 132 ?

I don't know but I can take a look.

It would require a non-trivial change and I am not sure that it is worth it. The simple fix does not work when the truncated part is a comment.

An alternative is to upgrade warning number 684 to an error via the command line option....

/message_set_to_error 684

This results in...

error 684 - There are (at least) 1 truncated line(s) in this file

but this could still be a false report when the truncated part is a comment.

Paul, Trusting compiler more than myself after truncation warning was set to error and then /no_truncate was introduced i just discovered deadly bug which was for 2 years when the limit which was hit was for 132 characters. Finding bugs becomes damn hard task when code is large, amount of possible reason for the bug growing so much that you feel totally lost. Now my first reaction on ANY problem with my codes is 'Oh no...'.

The truncation errors are the most hidden and will occur more and more often. This is because monitors become wider and wider and other languages (like HTML) show dumb examples of no limit lines (where i have seen >1000 character wide lines). So breaking the 132 character line limit in Fortran soon will be a common problem.

Since integer and real math is so different i do not find it wise to move to 'implicit none' generally just to avoid truncation and initialization errors because we will introduce even more hidden errors by mixing up integer variables starting with ijklmn thinking they are of type of integer but they are real or vise versa. You will be lazy to go 100000 lines up to check their definitions in the header which is as long as the phone book of decent size city. And with FTN95 programmer does not worry about forgetting initializations since FTN95 fights initialization errors with /undef or /checkmate and meantime these switches also check much more hidden code flow errors than initializations. It is much better to restrict yourself and know for sure immediately that variable starting with ijklmn is integer type, otherwise the code becomes barely manageable.

So, in my opinion, for the time being until all the limits like 72 and 132 will be in the past (for the net 20 years i think) the full fledged /no_truncate has to be implemented and even more - it has to be a default when you chose /full_debug

Dan,

Why don't you write a program that scans for lines longer than 132 characters and also for <HT> characters. You could either open the file using transparent:

      open (unit   = 11,               &
            file   = file_name,        &
            status = 'OLD',            &
            form   = 'UNFORMATTED',    &
            access = 'TRANSPARENT',    &
            iostat = iostat)
      write (*,2000) 'Opening file ',trim(file_name),' iostat = ',iostat
2000  format (a,a,a,i0)

or use normal reads and OPEN (LIN, FILE=NAME, STATUS='OLD', ACTION='READ', IOSTAT=IOSTAT) call READ_TABS@(LIN)

I have found scanning code for tab characters is useful, especially when reviewing code downloaded from forums. The old fixed format 7:72 limits are a bit more work, as I still have some old code with line numbers and edit notes in columns 73:. Makes for interesting bugs when you change the file name from .for to .f90 or .f95 !

John

/NO_TRUNCATE has now been extended so that it also works for free format files. The new feature will be in the next release of FTN95.

Thanks Paul for good news.

John, I have written such program for 72 characters 20 years ago and the conclusion is - i used it few times per year when some tough error had no explanation and this was useful. But using it every time was inconvenient. Still over long period of time like a year there was usually one case of such error. That means that the code was actually a lot of time - months - in buggy state. This is why /no_truncate could be very useful.

I started writing exclusively 132 wide sources only few years ago and thought that the problem with truncation for both 72 and 132 wide sources have been solved with introducing initially workaround by pushing truncation warning to be an error and then with /no_truncate compilation switch. Unfortunately both of them were working only for 72 character sources and as a result i thought for 2 years that opacity effects do not play any role in some our cases (and even rationalized some dumb explanation for that which was barely believable even to myself) but this was just plain truncation bug with source hitting 132 limit. This potentially (need to revisit this carefully) caused tremendous delay with one paper we were working for few years and still did not finish it