Attributes of file

(DanRRight, July 13, 2015) So, no, thanks. Implicit none is dead wrong approach with large codes if compiler has /undef. Yes, undef does not catch some rare errors. But it catches 1000 times more then implicit none. Dan is entitled to use whatever methods he prefers, but the justifications that he listed are incorrect.

First of all, IMPLICIT NONE and /undef are not mutually exclusive. We can use one or both or none, as appropriate to the situation at hand. IMPLICIT NONE is just one ingredient of static code checking, whereas /undef is just one ingredient of dynamic code checking.

There is more to debugging than just catching misspelled variable names, whether at compile time or at run time. A program may contain, in addition to misspelled variable names, incorrect argument lists passed to subroutines and functions, etc. With such errors present, even with /undef causing the program to issue an error and abort, you will still have to diagnose why the variable became undefined.

[u:78d621f218]Dynamic error checking, in general, and /undef, in particular, only covers those parts of the code that got executed in a particular run[/u:78d621f218]. Consider this code fragment

      if (iter > itmax) then 
         ierr = -1 
         call vperr (iprint, ierr, 1) 
         go to 95 
      endif 

Most of the time, the iterative algorithm that this code implements converges without *iter *exceeding itmax. If all the test runs worked this way, the entire body of subroutine vperr would never have been tested, whether or not the programmer used /undef. A few years later, a customer tries this code on a tougher problem, vperr gets executed, and lots of mysterious errors surface. Who gets the pleasure of finding the bugs in that case? Who gets the blame?

Dan's refusal to use IMPLICIT NONE, even occasionally, reminded me of the reason stated by some automobile passengers do not wear seat belts -- that wearing them might hinder a quick escape after a crash. A couple of months ago, Nobel Laureate John Nash and his wife Alice died in a taxi-cab crash on their way home in New Jersey (USA) from the airport. The Nashes were returning from a trip to Norway, where John Nash had just been honored with the Abel prize in mathematics. Neither was wearing a seat belt, and both were ejected from the taxi after the crash.

Mecej4,

Your comment that /implicit is a static check, while /undef is a dynamic check is a useful interpretation.

Unfortunately, I rely on static checks, as at present I have problems with FTN95's /checking options that change the operation of ALLOCATE and stop my programs from working. /debug is about all that I can use.

John

Quoted from JohnCampbell Mecej4,

Unfortunately, I rely on static checks, as at present I have problems with FTN95's /checking options that change the operation of ALLOCATE and stop my programs from working. /debug is about all that I can use.

John, I prefer static checks as well, since a single compilation run will flag all the errors that the compiler can detect in the source file; in some infrequent cases, the compiler cannot grok the code and may go haywire.

With /undef, on the other hand, you have to run the compile/link/test-run cycle for each error that is caught. For large programs, this can be slow. This is yet another reason why large programs (such as Dan's) cannot be debugged efficiently using only dynamic error checking.

As to the ALLOCATE bug, I urge you to create a reproducer (MWE) and submit it. We need to hunt these bugs down.

mecej4,

I have produced a reproducer, see: https://forums.silverfrost.com/Forum/Topic/2720

A compilation option of /ALLOCATE:GlobalAlloc or /GlobalAlloc to go with /CHECK could change this, although I don't know of what other related issues this would cause.

I did not consider using GET_STORAGE@ instead of ALLOCATE, as I wanted to test the production code and thought this would require too many changes.

John

Ah, now I see -- had you said something with 'allocatable array arguments' I would have recognized the topic sooner. Rather than relying on nonstandard allocation routines or compiler options that control how allocation is done, I think that FTN95 should consider implementing TR-15581 (see ftp://ftp.nag.co.uk/sc22wg5/N1351-N1400/N1379.pdf ). This TR filled a long felt need in Fortran-95 without requiring full F2003 implementation. The case for adding the TR is stated well in the introduction of the TR by John Reid:

There are many situations when programming in Fortran where it is necessary to allocate and deallocate arrays of variable size but the full power of pointer arrays is unnecessary and undesirable. In such situations the abilities of a pointer array to alias other arrays and to have non-unit (and variable at execution time) strides are unnecessary, and they are undesirable because this limits optimization, increases the complexity of the program, and increases the likelihood of memory leakage. The ALLOCATABLE attribute solves this problem but can currently only be used for locally stored arrays, a very significant limitation. The most pressing need is for this to be extended to array components; without allocatable array components it is overwhelmingly difficult to create opaque data types with a size that varies at runtime without serious performance penalties and memory leaks.

A major reason for extending the ALLOCATABLE attribute to include dummy arguments and function results is to avoid introducing further irregularities into the language. Furthermore, allocatable dummy arguments improve the ability to hide inessential details during problem decomposition by allowing the allocation and deallocation to occur in called subprograms, which is often the most natural position. Allocatable function results ease the task of creating array functions whose shape is not determined initially on function entry, without negatively mpacting performance.

long felt need

By whom, and for how long?

Quoted from LitusSaxonicum

long felt need

By whom, and for how long?

There have been many articles written about this -- in published books and journal articles, and postings in news:comp.lang.fortran . Fortran 90 had flaws in the way that it prescribed the role and behavior pointers, and this was rectified in Fortran 95. Fortran 95 still forces you to do most of the work of memory management in your own code, and it was still problematic to clean up user-allocated memory after an error.

A great example of the benefits of using allocatable arguments could be seen in the evolution of the HSL Galahad package (http://www.galahad.rl.ac.uk/ ). See, for example, the documented problems in the release notes of the earlier versions.

Mecej4,

Not an answer, as the cited website does not (as far as I can see) state that it is a need, nor for how long. I can see that it might be a very real need for some people, and the need may have been apparent for some time, but Reid was a co-author of Metcalf's in the book on Fortran 8X (90 - where X=10, I suppose), and the standards committee have had at least 4 goes (90, 95, 2003 and 2008) to get it right and haven't in 3 decades, so their judgement is rather questionable. (He's on the committee for 2015, so maybe he'll get it right at long last).

I can see, immediately, that allocatable memory solves some problems straight away, for example, when your program has a multiple document form, and in John's case, because the memory model of Windows has deficiencies for what he wants to do. On the other hand, plenty of real world problems are usefully solvable on a heck of a lot less memory than you get even in a cheap PC.

But, all this 'angels on a pinhead' stuff pales into insignificance against the need for a graphics standard and the tools for writing GUIs, which is where Clearwin+ is so brilliant, but it does tie you to Windows.

Eddie

Quoted from LitusSaxonicum ... the standards committee have had at least 4 goes (90, 95, 2003 and 2008) to get it right and haven't in 3 decades, so their judgement is rather questionable.

I do not agree with that conclusion, and do not want to discuss the matter here. There is a procedure that you can follow if you wish to send comments or put questions to the Fortran standards committees. John Campbell has some experience with that procedure, but I don't.

I can see, immediately, that allocatable memory solves some problems

That is not the topic of my response (Thu Jul 16, 2015) in this thread. The ALLOCATE statement (along with its friends DEALLOCATE, ALLOCATED(),..) was available in Fortran 90 and even some F77 compilers provided it as an extension in the 1980s. The topic was allocatable dummy arguments, which Silverfrost FTN95 does not have and which I suggested as a welcome addition.

The advantages of /undef are very hidden from the eyes. Those with large codes who actively expand them adding new and new features will mostly see them. You change something just a tiny bit and -- prepare to pull your last hairs - that typically causes chain reaction of multiple errors you did not expect. That how it works and why i say it is 1000 more valuable then static implicit none. Implicit none also gets very strong negative value slowing speed of debugging. I debug and search for the errors 100x more times then i write the code. Just wasted 3 days on elementary stuff i already have done 2-3 times before...despite of using /undef. Few times i was searching bugs for a month. One thing i can not find till today but that's in GUI - want to try for $150 if you solve that puzzle ?

Now i write the code and think about its permanent validation and control. For each subroutine seems it will be needed to write several ones which will check the results on consistency. And will help quickly find the bug if it will be introduced

Large codes eventually die because require too much time for managing them. Authors get tired to fix and expand them knowing that there exist some unexplained behavior caused most probably by the hidden bugs.

I wrote here how with /undef we found a gazillion of bugs in someone's 150 or 200k lines atomic code which after a decades of 'improvements' literally stopped to produce anything reasonable. And /undef still is periodically used to catch new bugs. It by the way heavily used implicit none 😃

Some errors would be harder to find without graphics and GUI - i agree with Eddie - so much of data is used and so complex codes become. I do not know how to include them into Standard since that is formally not a pure Fortran but something has to be eventually done. May be this compiler will be a good example for that in future. Without easy and a LOT of graphics, without advantages of self-explanatory and verbose GUI i would stopped my crazy fight with the bugs long long ago.

And I will not buy anyone's large code without passing /undef test. By the way may be Silverfrost must implement and use /undef in their C compiler which makes FTN95 if they have not done that.

Was thinking last days about a suggestion to Silverfrost to add the feature which will make needed variable undefined dynamically - that will be useful for debugging repetitive or iterative codes

I am not trying to convince everyone in using anything i use. Specifically /undef which i find genial, the #1 in value feature of this debugger. I tried many years ago, it rarely works. Few compilers though added them eventually. I am sure some people will find that useful to catch a deep stinking roach or two.

Quoted from DanRRight

I am not trying to convince everyone in using anything i use.

Sorry, I am not convinced that you are not. Especially because I see you asking that some compiler option be made a default, when it is so easy for you to make that personal choice for yourself in your ftn95.cfg file.

Specifically /undef which i find <...> the #1 in value feature of this debugger.

You are crediting the debugger with something that the compiler properly deserves credit for. All that the debugger does is to replace special bit patterns -- patterns that are reserved by the compiler to represent undefined values of integer, real, ..., types -- with the string 'UNDEFINED' in its variable displays. In fact, /undef works fine even when the debugger is not used at all.

The Control Data mainframes did something similar to trap indefinite and infinite real values in the late sixties and then in the seventies. See

 http://gsmall.us/Computing/CDC6400/Archive/CDC-6600-R-M_files/CDC-6600-R-M-3-18a.gif 

Most of us may find the representations of +0 and -0 somewhat surprising. The CDC used 1-s complement rather than the 2-s complement convention used in today's microprocessors.

On those machines, input was mostly by card deck or paper tape, and output by line printer -- of course all character based, no GUI.

Mecej4, I am not convincing anyone, i just suggest that if you have large code -- try to use /undef. I will be happy to see your face and swearing 'Oh, nooooo, WT@#$%!!!'

BTW, when I did not succeed, on any programming forums, anyone, who uses VI editor, to change it, i changed my views on humanity 😃

Quoted from DanRRight i just suggest that if you have large code -- try to use /undef.

I do use /undef regularly. But for /undef, /check and its fast compilation, I would probably have little use for FTN95. For me, however, /undef is one among many tools, suited for some purposes and irrelevant for others. I understand what it does, and I am happy with what it does. However, I don't think of it as a means of salvation.

I will be happy to see your face and swearing 'Oh, nooooo, T@#$%!!!'

I am afraid you'll have to be content with using a mirror to entertain yourself. I feel no urge to swear, although you do tempt me sometimes, and I don't anthropomorphize computer programs that way. Not every human being is a copy of DanRRight, please note. With the programs that I work with (mostly from Netlib and similar sources), it is quite normal to make a test run with known results with default compiler options, and only then make a run with /undef just as a final check. It is expected that nothing new will turn up, and that is what happens most of the time.

BTW, when I did not succeed, on any programming forums, anyone, who uses VI editor, to change it

Ed and vi/vim are tools that I use quite often. Perhaps you should consider leaving people alone -- given that your bugs need your full time attention and TLC, and you probably seek to outlive your bugs. Please see my back-of-the-envelope calculation (in https://forums.silverfrost.com/Forum/Topic/2760) to assess your chances of succeeding.

Perhaps this thread has reached a point where it has become tiresome to other forum readers. Please, let us close it here.

mecej4, this is public forum, open 24/7 for everyone to come and leave, thanks for participation, happy VI-ing, come again in good and even bad mood, we will be glad to hear from you.

As to others, we will continue. I'd recommend to all this program i received from JohnCampbell few days back on file attributes. Most useful about it to me is deciphering of encoded damn DOS attributes of files which produces FILES@.

Addition: I just noticed no IMPLICIT NONE in it. You do not have to if you like them, but, many thanks, John 😃

winapp 
 integer, external :: cbdropped 
 integer i

 i=winio@('%ww%es%si! Drop file here %ff&') 
 i=winio@('%dr&', cbdropped) 
 i=winio@('%pv%50.20cw[hscroll,vscroll]%ff&', 0) 
 i=winio@('%cn%bt[OK]') 
 End program 

 integer function cbdropped () 
   use clrwin 
   integer*4, parameter :: MaxLengOfFileNames  = 128 ! 320 
   integer*2, parameter :: maxNumbOfFilesInDir = 100 ! 32000

   character*(MaxLengOfFileNames) :: textsample
   character*(MaxLengOfFileNames) :: FileNameOfDroppedDataFor3D_GL02
   character*(MaxLengOfFileNames) :: FILES_InDir(maxNumbOfFilesInDir) 
! 
   integer*2 NumbOfFilesInDir 
   integer*2 ATTR_files(maxNumbOfFilesInDir)
   integer*2 date_files(maxNumbOfFilesInDir)
   integer*2 time_files(maxNumbOfFilesInDir) 
   real*8    file_size(maxNumbOfFilesInDir) 
!
   character dos_date*9, dos_time*8, datest*9, timest*8, dos_date_time*16, dttest*16
 !>    goto 10000     
     FileNameOfDroppedDataFor3D_GL02 = clearwin_string@('DROPPED_FILE') 

     write(*,*) 'FileNameOfDroppedDataFor3D_GL02=', FileNameOfDroppedDataFor3D_GL02 

     textsample = FileNameOfDroppedDataFor3D_GL02 
!
     call files8@ (textsample, NumbOfFilesInDir, maxNumbOfFilesInDir, FILES_InDir, ATTR_files, date_files, time_files, file_size) 
!
     datest = dos_date (date_files(1))
     timest = dos_time (time_files(1))
     dttest = dos_date_time ( date_files(1), time_files(1), .true. )
!
     print*, 'NumbOfFilesInDir=', NumbOfFilesInDir ! , 'textsample, NumbFiles_InDir ', textsample, NumbFiles_InDir 
     print*, ' name=', trim(FILES_InDir(1))
     print*, ' attr=', attr_files(1), ' ', dttest
     print*, ' date=', date_files(1), ' ', datest
     print*, ' time=', time_files(1), ' ', timest
     print*, ' size=', int(file_size(1))

 10000 cbdropped = 2 
 end function 

      character*9 function dos_date (yymmdd)
!
      integer*2 yymmdd
!
      character temp*9, label(0:12)*3
      integer*2 yy,mm,dd
      intrinsic mod
      data label / '___', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',     &
                   'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec' /
!
!     yyyyyyy mmmm ddddd
      dd = iand (yymmdd,31)             ! 0-31
      mm = iand (ishft(yymmdd,-5),15)   ! 0-15
      yy = ishft (yymmdd,-9)            ! 0-127
!
      yy = mod (yy+1980,100)
!
      write (temp,1001) dd,label(mm),yy
 1001 format (i2.2,'-',a3,'-',i2.2)
      dos_date = temp
      return
      end

      character*16 function dos_date_time (yymmdd, hhmmss, EST)
!
!   routine to return the date and time as a text string
!   to adjust time zone, the date can change > day > month > year change
!
      integer*2 yymmdd, hhmmss
      logical*4 est
!
      character temp*16, label(0:12)*3
      integer*2 max_day(0:12), yy,mm,dd, hh,mi,ss
      integer*4 values(8), dm
      intrinsic mod, iand, ishft
      data label / '___', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',     &
                   'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec' /
      data max_day /   0,    31,    28,    31,    30,    31,    30,     &
                      31,    31,    30,    31,    30,    31 /
!
!  use ishft to account for -ve hhmmss
!
!     yyyyyyy mmmm ddddd
      dd = iand (yymmdd,31)             ! 0-31
      mm = iand (ishft(yymmdd,-5),15)   ! 0-15
      yy = ishft (yymmdd,-9)            ! 0-127  ( 1980 to 2107 )
!
!     hhhhh mmmmmm sssss
      ss = iand (hhmmss,31)*2           ! 0-31
      mi = iand (ishft(hhmmss, -5),63)  ! 0-63
      hh = iand (ishft(hhmmss,-11),31)  ! 0-31
!
      if ( .not. EST ) goto 100
!
!   Adjust for time zone
!     Note : time zone adjustment 'dm' is for now and not when file was created
!     Daylight saving adjustment would be incorrect
!
      max_day(2) = 28
      if (mod(yy,4) == 0) max_day(2) = 29
!
      call DATE_AND_TIME ( VALUES = values )
      dm = values(4)
      write (*,*) 'dm =',dm
!
      if (dm > 0) then
         mi = mi + dm
 11      if (mi > 59) then
           mi = mi-60
           hh = hh+1
           goto 11
         end if
         if (hh <= 23)          goto 100
          hh = hh-24
          dd = dd+1
         if (dd <= max_day(mm)) goto 100
          dd = 1
          mm = mm+1
         if (mm <= 12)          goto 100
          mm = 1
          yy = yy+1
      end if
!
      if (dm < 0) then
         mi = mi+dm
 21      if (mi < 0) then
           mi = mi+60
           hh = hh-1
           goto 21
         end if
         if (hh >= 0)           goto 100
          dd = dd-1
          hh = hh+24
         if (dd >= 1)           goto 100
          mm = mm-1
          dd = dd + max_day(mm)
         if (mm >= 1)           goto 100
          yy = yy-1
          mm = 12
          dd = dd + 31
      end if
!
 100  yy = mod (yy+1980,100)
!
      write (temp,1001) dd,label(mm),yy, hh,mi
 1001 format (i2.2,'-',a3,'-',i2.2, i3,':',i2.2)
      dos_date_time = temp
      return
      end