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 

Please check if this crashes in your case
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Mon Nov 18, 2019 5:43 am    Post subject: Please check if this crashes in your case Reply with quote

This legacy functions to show the name of EXE file and the number of arguments when you call some xxx.exe program from the command prompt

C:> xxx.exe a b c

where a b c are parameters (total 3 here for example) from the times of FTN77 definitely has some very old devilry inside or i misuse something. It in some cases works and in another crashes the code. For example this first demo works ok showing the name of EXE file and that there are 3 arguments. But if i place declarations inside the module or call these functions from the subroutine it crashes. Compile ftn95 xxx.f95 /link /debug /64


Code:
CHARACTER*128 ProgEXEname, CMPROGNM@
integer*2 n_argComm_line, cmnargs@

  ProgEXEname = CMPROGNM@()
  n_argComm_line = cmnargs@()

print*, n_argComm_line, ' ', ProgEXEname 
pause

end

Code:
module mo
  use clrwin
  CHARACTER*128 ProgEXEname, CMPROGNM@
  integer*2 n_argComm_line, cmnargs@
end module

program aaa
use mo

  ProgEXEname = CMPROGNM@()
  n_argComm_line = cmnargs@()
   
print*, n_argComm_line, ' ', ProgEXEname 
pause

end
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2145
Location: Sydney

PostPosted: Mon Nov 18, 2019 7:30 am    Post subject: Reply with quote

Dan,

Use standard Fortran Intrinsic GET_COMMAND_ARGUMENT
Code:
      integer*4 Number, Length, Status
      character*250 ProgEXEname, Value
!
      do NUMBER = 0,99
        call GET_COMMAND_ARGUMENT( NUMBER, Value, LENGTH, STATUS )
        if ( number == 0 ) ProgEXEname = Value
        if ( status /= 0  ) exit
        write (*,11) number,length, status, trim(Value)
      end do
      write (*,*) 'Program : ',trim (ProgEXEname)
      write (*,*) 'num args =',number-1
   11 format (3i6,2x,a)
      end
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Nov 18, 2019 10:09 am    Post subject: Reply with quote

The program crashes at runtime because of missing routines. You get a warning about this at link time.

CMPROGNM@ and CMNARGS@ are FTN95 intrinsics. They are not declared in the standard module clrwin and can be used directly without referring to a standard module or INCLUDE file.

With the current release of FTN95 it is correct to provide the return type of these functions but this can't be done in a module otherwise the linker will look for your definition of these functions within your module (i.e. the compiler "mangles" the names of the routines with the name of the module).

Code:
module mo
  character*128 ProgEXEname
  integer*2 n_argComm_line
end module

program aaa
  use mo
  character*128 CMPROGNM@
  integer*2 CMNARGS@
  ProgEXEname = CMPROGNM@()
  n_argComm_line = CMNARGS@()
  print*, n_argComm_line, ' ', ProgEXEname
end
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Mon Nov 18, 2019 2:23 pm    Post subject: Reply with quote

Thanks John and Paul,
So, is this considered as valid Fortran behavior? I'm confused to use modules after that because do not know what's to expect from them if they can behave this way. This conflicts with my common sense
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Nov 18, 2019 4:00 pm    Post subject: Reply with quote

The code that you posted is not correct by any standards.

It would be better to follow John's recommendation.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Nov 19, 2019 1:03 am    Post subject: Reply with quote

My question is the following: besides the custom FTN95 specific functions@ how the declaration inside the modules and then USE them in main program instead of declaration in the main program can make the code non-standard? This cracks my brittle Fortran foundation, decently built on the sand, like an earthquake.

This is not a joke. Really can not afford having the major programming conceptual thing i do not understand. Ones more than a decade ago i started grand project to organize all my activity graphical way so that anything would be cataloged visually with clear dependencies like in a hierarchical tree. I almost done it when got unexplained crashes somewhere in the modules and after much efforts and swearing was forced to give up. Started again, failed and eventually stopped waiting for better times when users will report something similar and the compiler diagnostics will be more verbose. The ruins of this project are still waiting to be recovered but i got a painful experience that some things will be impossible to overcome and no one will help. Since then i am buried in millions files organized old stupid text way where i am permanently more and more lost. Finding things becomes way too annoying burden when you feel that eventually you will give up doing that. This soon could be compared to well known situations with some people who at some point failed with the disorder in their home and got few feet of mess they are unable to clean Sad
I have currently 7 different color Total Commanders each has two panels with bookmarks list 100-200 items long and many open tabs.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Nov 19, 2019 8:23 am    Post subject: Reply with quote

A module item called cmnargs@ (within the module mo) is "mangled" to something like mo!cmnargs@ (when the compiler reads it back in a USE statement). Your code implies that it is a function and the linker can't find it with the mangled name.

The mangled name identifies the scope and the context and serves to disambiguate it from other identifiers.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Nov 19, 2019 11:35 am    Post subject: Reply with quote

Isn't this just a bug? How come your own MAIN program does not understand your own library function with your own invention @ at the end in your own MODULE made by your own compiler written by your own stuff?

Now we have to assume that all other functions can be mangled even more?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1215

PostPosted: Tue Nov 19, 2019 3:00 pm    Post subject: Reply with quote

Dan, the behaviour that you are complaining about is standard in Fortran. Intrinsic functions and subroutines have properties that are slightly different from those of user provided functions and subroutines.

In particular, if a user provides a function called SQRT that returns the cube root of the argument, that function replaces the intrinsic SQRT. Certainly, you would not be using a name that is so obviously improper, but the compiler writer cannot anticipate all the names that users may give to their functions.

Silverfrost use names ending in '@' or '$' for their non-standard intrinsic procedures.

You don't seem to recognise that, in your module

Code:
module mo
  use clrwin
  CHARACTER*128 ProgEXEname, CMPROGNM@
  integer*2 n_argComm_line, cmnargs@
end module


CMPROGNM@ and cmnargs@ are variables in the DATA section, not symbolic constants in the CODE section. If you do not provide interfaces or the EXTERNAL attribute for these variables, they are not FUNCTION-s! If you give the EXTERNAL attribute, they are no longer intrinsic, and you have to provide them in an object file or library at link time.


Last edited by mecej4 on Wed Nov 20, 2019 2:44 pm; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Nov 20, 2019 1:16 pm    Post subject: Reply with quote

Why no interfaces are needed then for may other functions ?

winio@
select_graphics_object@
export_image@
DATE@, TIME@
rgb@
clearwin_info@
..........
..........
..........
..........
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1215

PostPosted: Wed Nov 20, 2019 2:30 pm    Post subject: Reply with quote

Section 12.3.1 of the Fortran 95 Standard says:

Quote:
The interface of an internal procedure, module procedure, or intrinsic procedure is always explicit in such a scoping unit.


I have underlined the part that I want to highlight. An intrinsic procedure, whether standard or a vendor-provided extension, has a fixed interface that is known to the compiler.

When we use intrinsic functions and subroutines in our code we can do so without having to provide an interface. This is a nice feature of the language since it makes it easier to write code using intrinsics, and makes that code easier to read without the clutter of numerous interfaces to intrinsic functions.

(There are special rules that apply when an intrinsic procedure is passed as a subprogram actual argument).
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Nov 20, 2019 3:10 pm    Post subject: Reply with quote

Then why interface for CMPROGNM@ and cmnargs@ is not provided?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1215

PostPosted: Wed Nov 20, 2019 3:27 pm    Post subject: Reply with quote

I can understand why the language of the standard can be a bit puzzling here -- specifically, what does "is explicit" mean here? It means that the interface is explicit a priori, without your having to do anything to make it so. This explicitness is similar to the explicitness of the interface to a contained procedure in the same program unit.

For a more detailed explanation, you may see C.9.3 Procedure interfaces (12.3), in the Fortran-95 Standard, available through this link:

https://wg5-fortran.org/N1151-N1200/N1191.pdf
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Nov 20, 2019 4:22 pm    Post subject: Reply with quote

Then looks like explicitness is not as explicit for some intrinsic functions versus another. For user natural to expect homogeneous treatment of all @ functions. If by some reason for some functions this is not possible then the help file has to start with the red flag and warnings in bold. Otherwise devilry in the codes will live for entire life
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1215

PostPosted: Wed Nov 20, 2019 5:29 pm    Post subject: Reply with quote

Your concerns are quite significant for using ClearWin+ with a different compiler such as Gfortran, as we can see in my recent problem report:

http://forums.silverfrost.com/viewtopic.php?p=28072#28072

With a compiler other than FTN95, the interfaces provided (clrwin$.mod, etc., and the source file from which the mod file may be generated) must be correct, otherwise a user will be stuck with mysterious crashes at run time.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page 1, 2, 3  Next
Page 1 of 3

 
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