Bug with TIME@()

According to the documentation TIME@() is a character*8 function.

    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)

    subroutine test () 
    character*32 cc
    character*8 time@ 
    cc = time@() 
    print*, cc
    return 
    end 
    program main
    call test
    end

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

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

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

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.

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

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

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 INTEGER2 or INTEGER8 arguments, which can cause problems on return.

John

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

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

      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.