Request to Remove all the Traces of INTEGER*2 from libraries

I probably lost a week of my life in 2 decades of using this compiler on searching for such bugs: some library functions which perfectly worked in dozens of my places in different codes abruptly stop working in new one. This is very painful feelings and loss of time, you feel completely lost why this happen. You reboot computer, reshuffle stack sizes, try all compiler switches, reduce array dimensions, return to previous code versions and so on and abruptly at the end of the day exhausted find the reason. The cause is in unusually declared Integer2 variables of some subroutines. This extremely easy to forget. With time things become even worse because you less and less expect such unjustified in modern computer age declarations which were probably introduced to save the memory. You expect Integer1 sometimes (storing rgb of image which might take 100 MB of storage), but you never expect integer*2 variables which save you just couple bytes !

This are variables in CISSUE@, in FILES@ etc. Please find the way to substitute them with default Integer*4 variables

Dan,

You could write your own library of interface routines, which would cover all integer2 arguments you don't like. Certainly dos_error_message@ and fortran_error_message@ are 2 I would include, as I always use integer4 values for IOSTAT. 'I think', given the way I4, I2 and I8 are stored, supplying an I4 or I8 value when an I2 is expected will not be a problem (see below). Expecting to receive I4 or I8 is when the problems occur. You can easily use ALLOCATE to make the temproary integer*2 fields, when required. ALLOCATE does not use the stack, as far as I'm aware, so you should not get too many stack overflows. With files@, there is files8@ which is to address file sizes > 2^31 bytes (another problem)

John

integer*8 ii
ii = 24842
call i8 (ii)
call i4 (ii)
call i2 (ii)
call i1 (ii)
end

subroutine i8 (ii)
integer*8 ii
write (*,*) 'i8 ',ii
end

subroutine i4 (ii)
integer*4 ii(2)
write (*,*) 'i4 ',ii
end

subroutine i2 (ii)
integer*2 ii(4)
write (*,*) 'i2 ',ii
end

subroutine i1 (ii)
integer*1 ii(8)
write (*,*) 'i1 ',ii
end

Some of these routines are so old that they might date back to when INTEGER*2 was the default. Anyway are you asking for a new set of library routines with different names but the same functionality? Would this solve the problem or would users forget to use the new names?

Paul, Years ago there was a saying 'It is the human nature to forget the modem cord in the hotel'. The solution is to make cords cheap or make internet wireless

We have to find the solution too

This is very typical error when you reuse the code numerous times. It is what all we do. We grab the piece of older text and land it into new place. We spend a millisecond looking on what kind of variables - character or real or integer - the compiler library routine needs if it is used. And when we do that second, third or more time this human nature starts to play the role, we always miss that integer is INTEGER*2. |This is a deadliest pitfall. It is easy to lose hours on this single line:

call cissue@(DOScommand,iOk)
 if(iOK.ne.0)  goto 10014

because if it will not work you will think that either the DOS command was wrong, files which this DOS command manipulates were missing or protected, specific DOS command needs special syntax (like REN which renames files for example) etc etc etc. You try instead

iOk=start_process@(DOScommand,' ') 

but it does not work too and you do not know why. Now you start to think the code is corrupt, the compiler is out of 2GB limit, stack size is bad etcetc. I showed here several times totally impossible bugs, but they happen

But the reason is that iOK in cissue@ is declared as INTEGER*2 to save you 2 bytes in the era of lamp computers. Why start_process@ stopped working needs more time to find, 6 months ago it worked fine...

Suggestions to address Integer*2 could be numerous. For example one that John Campbell offered above (i will think about it). Or make it strict error at compilation time when type mismatch happen for such older routines. Is this doable?

Not probably doable is when compiler has the abilities to collect programmer's habitual mistakes and politely suggest him that in humorous form 😃

Dan,

When I am not sure of the precision of the integer being returned, (especially the case with system timing routines), I select I*8 and initialise before the call, for example:

integer*8 iOk
...
iOk = 0
call cissue@(DOScommand,iOk) 
 if(iOK.ne.0)  goto 10014 

This should work for all possible kinds of iOK. You will see I used this approach in ELAPSE_SECOND, which I posted recently. John

I have read these posts but I am still not sure want is being requested. I could provide routines with different names but would this solve the problem?

My personal preference is that the help files refer to INTEGER2, INTEGER4 or INTEGER*8, as I always forget the kind values, which I never use. The compiler also discourages the use of these.

As for replacing all integer2 with integer4, what would be involved in providing generic routines so that any kind is supported ? or would this not be practical. The precision supplied must support the data being returned. This is not like the old Pr1me and Vax days where if you provided an integer4 value for an integer2, you got a totally different number. ( Is this the wrong indian ?) Certainly all the intrinsic functions support this and early proponents of Fortran 90+ told us how writing generic routines was such a good thing. I once tried, only to be told by FTN95 that I had a mixed mode error. Maybe I got my code wrong !! There is not a lot said about generic procedures in the help file and I would not clasify them as a must have, as I've never had to use them in 15 years of using ftn95.

The routines which do confuse me are the less documented ones, including 'QueryPerformanceFrequency' and 'QueryPerformanceCounter' where I think they require an INTEGER8. I'm not sure so I supply an integer8 so that if an I*4 is returned, the code still works.

My 3 cents worth also.

John

I have nothing against changing variables to I4 across the whole routines. Since the compiler developers completely control these libraries, compiler has to generate an error on using INTEGER2 with the message that obsolete INTEGER2 variables are routinely changed to default INTEGER4. We will need to recompile the codes, but if error/warning will be issued at compilation time, then it will be easy.

I have nothing against new names in the libraries too. If in this case the FTN95 Help will emphasize the difference with the older functions or better have the hyper-linkable cross-references for easy access and comparison like it was in older Help, everyone will be happy

(as we already discussed this in other threads, it's not like it is right now, when the Help just says : 'See also ...'. If the developers of this compiler want this compiler sales to grow exponentially, not to decay exponentially, then, according to the salespeople's law #1, they have to permanently keep attention of the users on their product, continuously offering numerous options. And this compiler has tons of such options, it is the richest one among all of them, but nobody in the world just knows that and the poor Help, not many flashy applications, not easily organized Demos, not many great Examples or useful Fortran code snippets is more causing the decay, then the grow of interest to it. Why do i care? Simply, because the more customers, the more new options and the less bugs in the product )

It would be better if these library routines were made insensitive to the precision of the variables being used by the programmer. This is no different to the intrinsic Fortran functions like 'ABS', at one time you needed to use 'IABS' and 'DABS' for integer and double precision, but that restriction was lifted long ago, why not with these FTN95 functions which are essentially intrinsic functions in their own right. Ian

Great, Ian. How about that solution, Paul?

Ian is spot on. I was thinking along those lines, but couldn't find the right term for it before something else cropped up and diverted me. How difficult would it be to make the offending functions generic (I think that is the right term).

Eddie

I will see if this can be done without too much effort. It won't be the same as the standard intrinsics which are handled by the compiler. If its possible it would be via modules and module procedures. I have used module procedures for different types (e.g. INTEGER and REAL) but not for INTEGERs of different sizes.