forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

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

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2235
Location: South Pole, Antarctica

PostPosted: Tue Jun 01, 2010 3:28 am    Post subject: Request to Remove all the Traces of INTEGER*2 from libraries Reply with quote

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 Integer*2 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 Integer*1 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
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Tue Jun 01, 2010 6:26 am    Post subject: Reply with quote

Dan,

You could write your own library of interface routines, which would cover all integer*2 arguments you don't like. Certainly dos_error_message@ and fortran_error_message@ are 2 I would include, as I always use integer*4 values for IOSTAT.
"I think", given the way I*4, I*2 and I*8 are stored, supplying an I*4 or I*8 value when an I*2 is expected will not be a problem (see below). Expecting to receive I*4 or I*8 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

Code:
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


Last edited by JohnCampbell on Tue Jun 01, 2010 11:33 am; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6593
Location: Salford, UK

PostPosted: Tue Jun 01, 2010 7:28 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2235
Location: South Pole, Antarctica

PostPosted: Tue Jun 01, 2010 8:48 pm    Post subject: Reply with quote

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:

Code:
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

Code:
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 Smile
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Wed Jun 02, 2010 12:55 am    Post subject: Reply with quote

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:
Code:

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6593
Location: Salford, UK

PostPosted: Wed Jun 02, 2010 9:03 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message AIM Address
brucebowler
Guest





PostPosted: Wed Jun 02, 2010 1:19 pm    Post subject: Reply with quote

I can't speak for the OP but I'd like to see (and yes I know it's a compatibility issue, I'm well aware of that) the same routine names but with single precision integer variables (ie I*4).

Everyone will suffer the first time the compile/run a program after the change but we'll all be better off after that.

Just my $0.03 (inflation)
Back to top
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Wed Jun 02, 2010 2:20 pm    Post subject: Reply with quote

My personal preference is that the help files refer to INTEGER*2, INTEGER*4 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 integer*2 with integer*4, 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 integer*4 value for an integer*2, 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 INTEGER*8. I'm not sure so I supply an integer*8 so that if an I*4 is returned, the code still works.

My 3 cents worth also.

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2235
Location: South Pole, Antarctica

PostPosted: Wed Jun 02, 2010 6:25 pm    Post subject: Reply with quote

I have nothing against changing variables to I*4 across the whole routines. Since the compiler developers completely control these libraries, compiler has to generate an error on using INTEGER*2 with the message that obsolete INTEGER*2 variables are routinely changed to default INTEGER*4. 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 )
Back to top
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 474
Location: Sunderland

PostPosted: Thu Jun 03, 2010 12:41 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail
DanRRight



Joined: 10 Mar 2008
Posts: 2235
Location: South Pole, Antarctica

PostPosted: Thu Jun 03, 2010 2:48 pm    Post subject: Reply with quote

Great, Ian. How about that solution, Paul?
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2187
Location: Yateley, Hants, UK

PostPosted: Thu Jun 03, 2010 3:08 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6593
Location: Salford, UK

PostPosted: Thu Jun 03, 2010 8:47 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group