View previous topic :: View next topic |
Author |
Message |
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Tue Jul 19, 2016 4:45 pm Post subject: Bug with TIME@() |
|
|
According to the documentation TIME@() is a character*8 function.
Code: | subroutine test ()
include <clearwin.ins>
character*32 cc
cc = time@()
return
end
|
This small example provides error 1173 - Only CHARACTER variables can be assigned to CHARACTER variables, found REAL(KIND=1) |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Tue Jul 19, 2016 5:14 pm Post subject: |
|
|
Code: | subroutine test ()
character*32 cc
character*8 time@
cc = time@()
print*, cc
return
end
program main
call test
end |
|
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Jul 19, 2016 7:15 pm Post subject: |
|
|
Paul's reply is rather terse, and you would get it working, but wouldn't understand why from following his example.
The point is that function subprograms supplied with FTN95 (and FTN77 before it) must have their type declared, because otherwise they are assumed to have the implicit type, which is REAL for 't'.
If you had followed the IMPLICIT NONE route, you would have got an error message. You would also have to do the same for function subprograms you wrote yourself.
Eddie |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Wed Jul 20, 2016 9:53 am Post subject: |
|
|
Paul,
that looks to me like a joke. Why do I need to declare a library function which is defined? How can I know which library functions needs to be declared and which are already declared in clearwin.ins?
Erwin |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed Jul 20, 2016 10:55 am Post subject: |
|
|
Erwin
TIME@ is a legacy FTN77 function that does not appear in any of the standard header files and the compiler needs to know that its return type is not the default type for names starting with T.
I guess that we could create a header file for all of the legacy FTN77 functions but then you would need to know to include it in the program.
I hope that we will be able to address this issue together with the associated complaints about inadequate documentation in due course but the good news is that users can usually get a quick response from this Forum.
Paul |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Jul 20, 2016 12:00 pm Post subject: |
|
|
Erwin,
It has always been this way. Many extra functions don't need an explicit type declaration because they conform to the implicit type conventions, but CHARACTER functions can never do so.
You have to declare WINIO@ as INTEGER if you don't use the windows.ins (or other), and your callback functions need to be:
INTEGER, EXTERNAL ::
It is a foible of FTN95 that EXTERNAL alone is enough, because being EXTERNAL overrides the type declaration.
The legacy FTN77 functions are very useful, and should be more widely appreciated. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Jul 21, 2016 1:21 pm Post subject: |
|
|
I have written a program to convert CLEARWIN.INS from fixed format to wide free format, so each C_EXTERNAL definition and it's alias are all lined up. Unfortunately, the maximum line length is 153, but it does provide a much more informative list of Clearwin+ routines.
I suspect the next step is to locate all other routine@ functions and declare their type.
There are some of functions that don't need declaring. I thing CPU_CLOCK@ is one of them.
It would be good to have an INTERFACE include file for all Silverfrost library routines that do not require a C_EXTERNAL definition, although I would prefer the non-standard use of INTEGER*4, rather than KIND(3).
Scanning the index of FTN95.chm indicates this would be a lot of work, although could be generally useful.
John |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Thu Jul 21, 2016 1:38 pm Post subject: |
|
|
Hi John,
Clearwin.ins is written so it is equally usable in free or fixed format already! Converting it to 153 column free format removes half of its usefulness.
Eddie |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Jul 21, 2016 1:50 pm Post subject: |
|
|
Eddie,
I don't think I agree with your use of the term "usefulness" !
although anyone who prefers fixed format may agree with your comment.
The following is a link to what I generated. There is more that could be done. I find this presentation more readable.
https://www.dropbox.com/s/s56szwix24xe95r/clearwin_wide_2.ins?dl=0
I do like the idea of an INTERFACE include file for all library routines. It may catch some of the INTEGER*2 or INTEGER*8 arguments, which can cause problems on return.
John |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Thu Jul 21, 2016 2:08 pm Post subject: |
|
|
John,
Take issue with my half, if you must. On usefulness I stand my ground.
A dual format INTERFACE file would be useful - doubly useful.
Eddie |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Sat Jul 23, 2016 10:57 pm Post subject: |
|
|
John,
Intel made things differently, and long long ago. Instead of pure consmetics like you are suggesting they decyphered the mess of those REFs and VALs in this heap of nonsense i always avoid to look thouigh sometimes need to know what they specifically mean
Code: | C_EXTERNAL GET_SYSTEM_FONT@ 'get_system_font' (REF,REF,REF,REF,REF,REF,REF,REF,REF,REF,REF,REF,REF,OUTSTRING) |
This ones was very important to me for the network/internet related additions to Fortrtan like in Intel's ININET (if my memory still works). I failed to make connection to arbitrary secure server, connect to the site and control the site from my computer using Silverfrost compiler though from any other compiler it is easily possible. I never returned to this since then. |
|
Back to top |
|
|
|