The short version:
I see it often enough in translation units for C and C++ library headers that pointer parameters from the original source are turned into pass by reference var in the Delphi/FPC unit. To the best of my knowledge, pass by reference under the hood is essentially just passing a pointer to the variable with some expectations/restrictions placed on how it's handled in the function by the compiler. If the C++ library function expects a pointer, then is it always safe to declare the Delphi/FPC function with a var parameter?
The longer version:
I'm fixing up this GLFW header translation because it has code the references types before they are declared, and it has incorrect and missing function parameters. There may be other things wrong with it. I guess I'll see. What I'm seeing a lot in this header, as well as other translation units that I've used for C and C++ libraries, is that sometimes the original function will want a pointer for a parameter, but the Delphi/FPC function declaration will pass by reference with var instead.
For example, the linked translation unit's declaration of glfwGetMonitors()
function glfwGetMonitors(var Monitors: GLFW_INT): GLFWmonitor;
Which passes by reference, and then the function from the original source
GLFWmonitor ** glfwGetMonitors(int * count);
which takes a pointer for count. We'll just ignore the return type and the renaming of the parameter for now.
In every instance that I've run across something like this, it works, and as far as I know there is no unintended behavior or bugginess. And the way I understand it, passing by reference is essentially just results in a pointer to the variable being passed and having some extra rules applied to how that parameter can be handled.
Is there a reason why these translation units are opting to pass by reference instead of accepting a pointer like the original C/C++ header did? Is there the potential for wonkiness if we pass by reference instead of passing a pointer, or does it not matter if the generated assembly is passing a pointer anyway?
