Localize the range of common block variables in Fortran 77 - fortran

I'm working on this F77 code with extensive use of COMMON BLOCKS, and those COMMON BLOCKS are also used in a C program (after name mangling). If foo(a, b, ...) is the main routine of the fortran code, is there anyway to make the COMMON BLOCKS local to foo() so I can do something like the following?
program new_control_routine()
...
call foo(a1,b1,...)
...
call foo(a2,b2,...)
...
end
The point is to have multiple calls of "foo" with each of them having independent COMMON BLOCKS, even though they those blocks have the same names. The only way I know is to rename the COMMON BLOCKS and related subroutines in the second call of "foo", so it becomes another routine "foo1", so I can do:
programe new_control_routine()
...
call foo(a1,b1,...)
...
call foo1(a2,b2,...)
But this is certainly mundane and error-prone.

The point of common blocks is that they are global, accessible to any routine that uses their name. Could you make the variables in the common blocks arrays, and pass an index, so that your different calls accessed different elements?
Why limit yourself to FORTRAN 77? With Fortran 95/2003 you could create a user-defined type and create a array-variable of that type. Then you pass the index of the element that you want to work on. The user-defined type can be a complex group of variables. The variable can either be an argument to the subroutines or a module variable.

Related

Value not passing to subroutine using a common block

I'm trying to pass a parameter between a Fortran main program and a subroutine. However for some reason a different value is obtained in the subroutine. I am using common blocks.
program main
nzcur=1
write(*.*)"nzcur in main",nzcur
call hit
subroutine hit
common/part/nzcur
write(*,*)"nzcur in hit",nzcur; pause
end
end program
I would expect nzcur=1 but I get nzcur=0.
I think it could be a data type mismatch as I do not define it, only as a common block.
As noted in the comments, the correct learning response to this question is to avoid using common blocks to have access to variables from other scopes. In writing code in the modern era there are far better ways (more later).
Fortunately, however, we can look at this question in terms of "how do I understand what is happening with this common block?". Such a question is useful to those unfortunate programmers trying to understand old (or badly written new) code.
In considering the program of the question one should note that several corrections are required to have compilable code (with different possible approaches). The errors there are not directly relevant to the discussion.
In the subroutine
subroutine hit
common/part/nzcur
write(*,*)"nzcur in hit",nzcur; pause
end
we have a named common block called part, with one numeric storage unit which contains the integer variable nzcur (thanks to implicit typing).
In the question there is clearly the expectation that the variable nzcur in this common block accesses some other variable called nzcur and that this other variable is the one in the main program called nzcur. This is not correct.
nzcur in the subroutine is associated only with the first numeric storage unit of any other common block named part. The association is not based on named or location in the common block definition.
In the program of the question, there is no other common block called part; nzcur of the subroutine is not associated with anything else. It is certainly not associated with a variable not in a common block.
Because of this lack of association, the variable is not defined by the time the write statement references it. Again, the definition of the variable in the main program does not affect the definition of the local variable in the subroutine.
To "correct" the association, it will be necessary to put the variable nzcur of the main program in the correct location in a common block named part (in the main program).
To answer the question of "how do I set the value of nzcur in the subroutine without using common blocks?", refer to other questions such as this one.

How to identify uninitialized variables in a Lua script, without running it

I'd like to be able to write some Lua code like this:
y=x+1
and be able to get the names of all variables (x and y in this case) so that I can read from/write to them in the calling C++ program. The problem is that x is uninitialized, so this chunk will not execute and therefore neither variable will appear in the globals table. My current work-around is to have the user explicitly declare that they want to initialize x externally (as well as how to initialize it), then I pre-pend the Lua script with an appropriate declaration for x, so that the final script looks like this:
x= /*some value calculated outside of the Lua script*/
y=x+1
Although this works, I'd really like to have a way to automatically list all uninitialized variables in the Lua code and present them to the user, instead of the user having to remember to explicitly declare them. A function that parses the Lua code without executing it would probably be what I want. I've tried the function luaL_loadstring, but x and y don't show up in the globals table.
Since this is a bit vague, I'll give an actual use case. My C++ code basically performs optimizations on functions, such as finding a root or a maximum. I want the user to be able to define custom functions (in the form of Lua scripts), which in general will have one or more inputs and one or more outputs. The user will define which parameters the optimizer should operate on. For example, the user may want to find the minimum of y=x^2. The way I'd like it to work is that the user writes a Lua script consisting of nothing more than y=x^2, and then tells the optimizer to vary x in order to minimize y. On each iteration of the optimizer, the current guess for x would be automatically pasted into the user script, which is then executed, and then the value of y is pulled from the Lua state to be fed back to the optimizer. This is how I have it working now, however it's a bit clumsy from a UX perspective because the user has to manually declare that x is a Lua variable. This gets tedious when there are many variables that require manual declaration. It would be much better if I could automatically scan the script and show the user a list of their undeclared variables so they could then use drag-and-drop and other GUI sugar to do the manual declaration.
Lua isn't meant to work like that. Lua/C interop is intended to be collaborative; it's not supposed to be that C can do whatever it wants.
Using your example, if you have a Lua script that is supposed to take a value from C and return that value + 1, then you spell that in Lua like this:
local x = ... --Get the first parameter to the chunk.
return x + 1 --Adds 1 to the value and returns it.
You compile this string into a Lua chunk and call it like a Lua function. You pass it the value you want to manipulate and get the return value from the Lua stack.
The idea is not that C code can just reach into a Lua script and shove data into it arbitrarily. The above chunk takes parameters from the user and provides return values to the user. That's typically how C interfaces with Lua.
Yes, you can write values to globals and have the Lua script read them, and write its "results" to globals that the external code reads. But this is not the most effective way to interact with scripts.
I'd really like to have a way to automatically list all uninitialized variables
There's no such thing in Lua as an "uninitialized variable". Not in the way that you mean.
Yes, there are globals. But whether that global has a value or not is not something the Lua script can control. A global is global after all; you can set a global variable from outside of the script (for example, see lua_setglobal). If you do, then a script that reads from it will read the value you set. But it doesn't know anything about that.
What you want is a static code analyzer/Lua linter. Take a look at Luacheck:
Luacheck is a static analyzer and a linter for Lua. Luacheck detects
various issues such as usage of undefined global variables, unused
variables, and values, accessing uninitialized variables, unreachable
code and more. Most aspects of checking are configurable: there are
options for defining custom project-related globals, for selecting set
of standard globals (version of Lua standard library), for filtering
warnings by type and name of related variables, etc. The options can
be used on the command line, put into a config or directly into
checked files as Lua comments.
There is also Lualint, and similar Lua linters for Atom, VSCode, or your fav IDE.

How do I specify runtime constants in (modern) Fortran?

I'm working on a Fortran 2008 project in which I read some parameters (including both scalars and arrays) from an input file using read statements. I would like to enforce that these parameters not be modified after they are read in. How can I achieve this?
Module variables can be given the PROTECTED attribute, which prevents code USE'ing the relevant module from modifying the module variable through the name of the variable.
However this does not prevent modifications to the variable from within the defining module or its descendant submodules, or modifications to the variable through means other than the use associated name (e.g. through a pointer associated with the same thing), or stop non-conforming Fortran code from modifying the variable (e.g. by the use associated name being used as an actual argument to a procedure with implicit interface that modifies the corresponding dummy).
In fortran 90, You can define a module that has those variables as private member. Let the module define only the function to read your variables from file, and getter functions that return their values. And no other function in the module.
I do not use the OO capability offer by fortran 2003 an fortran 2008, but the scenario will be similar.

Is It Necessary to declare the Type of User-Defined Functions in ANY Calling Routine?

I use the Intel Visual Fortran. According to Chapmann's book, declaration of function type in the routine that calls it, is NECESSARY. But look at this piece of code,
module mod
implicit none
contains
function fcn ( i )
implicit none
integer :: fcn
integer, intent (in) :: i
fcn = i + 1
end function
end module
program prog
use mod
implicit none
print *, fcn ( 3 )
end program
It runs without that declaration in the calling routine (here prog) and actually when I define its type (I mean function type) in the program prog or any other unit, it bears this error,
error #6401: The attributes of this name conflict with those made accessible by a USE statement. [FCN] Source1.f90 15
What is my fault? or if I am right, How can it be justified?
You must be working with a very old copy of Chapman's book, or possibly misinterpreting what it says. Certainly a calling routine must know the type of a called function, and in Fortran-before-90 it was the programmer's responsibility to ensure that the calling function had that information.
However, since the 90 standard and the introduction of modules there are other, and better, ways to provide information about the called function to the calling routine. One of those ways is to put the called functions into a module and to use-associate the module. When your program follows this approach the compiler takes care of matters. This is precisely what your code has done and it is not only correct, it is a good approach, in line with modern Fortran practice.
association is Fortran-standard-speak for the way(s) in which names (such as fcn) become associated with entities, such as the function called fcn. use-association is the way implemented by writing use module in a program unit, thereby making all the names in module available to the unit which uses module. A simple use statement makes all the entities in the module known under their module-defined names. The use statement can be modified by an only clause, which means that only some module entities are made available. Individual module entities can be renamed in a use statement, thereby associating a different name with the module entity.
The error message you get if you include a (re-)declaration of the called function's type in the calling routine arises because the compiler will only permit one declaration of the called function's type.

Passing function pointers as an API interface to a compiled library

Dearest stack exchange,
I'm programming an MRI scanner. I won't go into too much background, but I'm fairly constrained in how much code I've got access to, and the way things have been set up is...suboptimal. I have a situation as follows:
There is a big library, written in C++. It ultimately does "transcoding" (in the worst possible way), writing out FPGA assembly that DoesThings. It provides a set of functions to "userland" that are translated into (through a mix of preprocessor macros and black magic) long strings of 16 bit and 32 bit words. The way this is done is prone to buffer overflows, and generally to falling over.*
The FPGA assembly is then strung out over a glorified serial link to the relevant electronics, which executes it (doing the scan), and returning the data back again for processing.
Programmers are expected to use the functions provided by the library to do their thing, in C (not C++) functions that are linked against the standard library. Unfortunately, in my case, I need to extend the library.
There's a fairly complicated chain of preprocessor substitution and tokenization, calling, and (in general) stuff happening between you writing doSomething() in your code, and the relevant library function actually executing it. I think I've got it figured out to some extent, but it basically means that I've got no real idea about the scope of anything...
In short, my problem is:
In the middle of a method, in a deep dark corner of many thousands of lines of code in a big blob I have little control over, with god-knows-what variable scoping going on, I need to:
Extend this method to take a function pointer (to a userland function) as an argument, but
Let this userland function, written after the library has been compiled, have access to variables that are local to both the scope of the method where it appears, as well as variables in the (C) function where it is called.
This seems like an absolute mire of memory management, and I thought I'd ask here for the "best practice" in these situations, as it's likely that there are lots of subtle issues I might run into -- and that others might have lots of relevant wisdom to impart. Debugging the system is a nightmare, and I've not really got any support from the scanner's manufacturer on this.
A brief sketch of how I plan to proceed is as follows:
In the .cpp library:
/* In something::something() /*
/* declare a pointer to a function */
void (*fp)(int*, int, int, ...);
/* by default, the pointer points to a placeholder at compile time*/
fp = &doNothing(...);
...
/* At the appropriate time, point the pointer to the userland function, whose address is supplied as an argument to something(): /*
fp= userFuncPtr;
/* Declare memory for the user function to plonk data into */
i_arr_coefficients = (int) malloc(SOMETHING_SENSIBLE);
/* Create a pointer to that array for the userland function */
i_ptr_array=&i_arr_coefficients[0];
/* define a struct of pointers to local variables for the userland function to use*/
ptrStrct=createPtrStruct();
/* Call the user's function: */
fp(i_ptr_array,ptrStrct, ...);
CarryOnWithSomethingElse();
The point of the placeholder function is to keep things ticking over if the user function isn't linked in. I get that this could be replaced with a #DEFINE, but the compiler's cleverness or stupidity might result in odd (to my ignorant mind, at least) behaviour.
In the userland function, we'd have something like:
void doUsefulThings(i_ptr_array, ptrStrct, localVariableAddresses, ...) {
double a=*ptrStrct.a;
double b=*ptrStrct.b;
double c=*localVariableAddresses.c;
double d=doMaths(a, b, c);
/* I.e. do maths using all of these numbers we've got from the different sources */
storeData(i_ptr_array, d);
/* And put the results of that maths where the C++ method can see it */
}
...
something(&doUsefulThings(i_ptr_array, ptrStrct, localVariableAddresses, ...), ...);
...
If this is as clear as mud please tell me! Thank you very much for your help. And, by the way, I sincerely wish someone would make an open hardware/source MRI system.
*As an aside, this is the primary justification the manufacturer uses to discourage us from modifying the big library in the first place!
You have full access to the C code. You have limited access to the C++ library code. The C code is defining the "doUsefullthings" function. From C code you are calling the "Something" function ( C++ class/function) with function pointer to "doUseFullThings" as the argument. Now the control goes to the C++ library. Here the various arguments are allocated memory and initialized. Then the the "doUseFullThings" is called with those arguments. Here the control transfers back to the C code. In short, the main program(C) calls the library(C++) and the library calls the C function.
One of the requirements is that the "userland function should have access to local variable from the C code where it is called". When you call "something" you are only giving the address of "doUseFullThings". There is no parameter/argument of "something" that captures the address of the local variables. So "doUseFullThings" does not have access to those variables.
malloc statement returns pointer. This has not been handled properly.( probably you were trying to give us overview ). You must be taking care to free this somewhere.
Since this is a mixture of C and C++ code, it is difficult to use RAII (taking care of allocated memory), Perfect forwarding ( avoid copying variables), Lambda functions ( to access local varibales) etc. Under the circumstances, your approach seems to be the way to go.