Please check if this crashes in your case

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

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

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

print*, n_argComm_line, ' ', ProgEXEname  
pause

end

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

Dan,

Use standard Fortran Intrinsic GET_COMMAND_ARGUMENT integer4 Number, Length, Status character250 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

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).

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

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

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

It would be better to follow John's recommendation.

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 😦 I have currently 7 different color Total Commanders each has two panels with bookmarks list 100-200 items long and many open tabs.

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.

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?

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

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.

Why no interfaces are needed then for may other functions ?

winio@ select_graphics_object@ export_image@ DATE@, TIME@ rgb@ clearwin_info@ .......... .......... .......... ..........

Section 12.3.1 of the Fortran 95 Standard says:

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).

Then why interface for CMPROGNM@ and cmnargs@ is not provided?

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

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

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.

I'm still puzzling where these several functions are so different so that they are not included by default into special treatment interface list.

Here is an example you would not find the error for a long time because these two-there functions create pure unimaginable devilry. See bubble help in light yellow on SDBG screenshot how initialized variable becomes undefined (!!!) after calling these two functions the way i have shown above ? If compiler would not support /UNDEF (or the same /CHECKMATE ) you will not find this bug. I had similar bugs for decades because users in 999 out of 1000 cases when find the bug procrastinate to report it. Even though FTN77/90/95 had /UNDEF from the start, the debugger in some cases was also having bugs which did not allow to apply /DEBUG or /UNDEF for the code or with /DEBUG the bug disappeared. Thanks to integral effect of lazy reporting and usage over time the compilers and debuggers now rarely having problems.

About bugs. I'd say the company (and all people in general) have absolutely wrong attitude respect to reported bugs. All software has bugs. And instead of feeling kind of guilt the SF should encourage users to be like a quality assurance (QA) guard for the software. I'd introduce even competition for 'QA winner of the year' based on how many problems were reported in 365 days. I'd personally donate for that purpose, say, a $100. This will return back in the future with the saved time and programs quality.

Dan

You are presumably using the debugger and currently stepping through the program.

I think you are running the 64 debugger directly from Plato so you probably don't have the fix that provides the correct break point line. In this case the information provided by the debugger will be out of sync.

If the debugger is working correctly and you hover over a variable then it will show its state in relation to the current break point. So your image would be correct if the current break point was before the assignment.

Program stopped at break point where kCreateFields variable was used in the IF (kCreateFields.eq.1) THEN, that's much below of all these lines i pictured above. The error was telling me that the variable was ... undefined! I specifically went with debugger up and made a picture of something unimaginable.

Then i removed the CMPROGNM$ and cmnargs$ and program started working OK. It also started working OK if i declare these functions in the MAIN program where they were used

If you are able to provide more of the code (particularly before this) then I might be able to understand what is wrong.

I will send you the complete code which is not large. But why the demo what i posted above is not enough? The undefined bug is the consequence of the same problem shown in the first message. It is not worth to cure consequence, there could be infinite amount of them