Function returning macro? - macros

I'm investigating the Linux kernel where I came across multiple functions that have the following syntax. I'm confused about what this syntax means. I'm not interested what the function does, but what the syntax means.
static int __init customize_machine(void)
{
...
return 0;
}
Here, __init is a macro. It says return 0, so it returns an int, but what is the __init macro doing there?
Also, the macros are found at the end of the function name declaration:
static noinline void __init_refok rest_init(void) __releases(kernel_lock)
{
...
}
Same question: what is the purpose of this macro?

This function is a part of a linux kernel module. The __init macro can be found in linux/module.h. Use it like module_init(customize_machine) and becomes the init function of the module. Returning 0 means the module is loaded successfully.

Related

How to control argument passing policy in pybind11 wrapping of std::function?

I have a class in c++ that I'm wrapping into python with pybind11. That class has a std::function, and I'd like to control how the arguments to that function are dealt with (like return value policies). I just can't find the syntax or examples to do this...
class N {
public:
using CallbackType = std::function<void(const OtherClass*)>;
N(CallbackType callback): callback(callback) { }
CallbackType callback;
void doit() {
OtherClass * o = new OtherClass();
callback(o);
}
}
wrapped with
py::class_<OtherClass>(...standard stuff...);
py::class_<N>(m, "N")
.def(py::init<N::CallbackType>(),
py::arg("callback"));
I all works: I can do this in python:
def callback(o):
dosomethingwith(o)
k = N(callback)
, but I'd like to be able to control what happens when callback(o); is called - whether python then will take ownership of the wrapped o variable or not, basically.
I put a printout in the destructor of OtherClass, and as far as I can tell, it never gets called.
OK, I think I figured it out:
Instead of std::function, use a pybind11::function:
using CallbackType = pybind11::function
and then
void doit(const OtherClass &input) {
if (<I want to copy it>) {
callback(pybind11::cast(input, pybind11::return_value_policy::copy));
} else {
callback(pybind11::cast(input, pybind11::return_value_policy::reference));
}
}
I see nothing in pybind11/functional that allows you to change the ownership of the parameters at the point of call, as the struct func_wrapper used is function local, so can not be specialized. You could provide another wrapper yourself, but in the code you can't know whether the callback is a Python function or a bound C++ function (well, technically you can if that bound C++ function is bound by pybind11, but you can't know in general). If the function is C++, then changing Python ownership in the wrapper would be the wrong thing to do, as the temporary proxy may destroy the object even as its payload is stored by the C++ callback.
Do you have control over the implementation of class N? The reason is that by using std::shared_ptr all your ownership problems will automagically evaporate, regardless of whether the callback function is C++ or Python and whether it stores the argument or not. Would work like so, expanding on your example above:
#include <pybind11/pybind11.h>
#include <pybind11/functional.h>
namespace py = pybind11;
class OtherClass {};
class N {
public:
using CallbackType = std::function<void(const std::shared_ptr<OtherClass>&)>;
N(CallbackType callback): callback(callback) { }
CallbackType callback;
void doit() {
auto o = std::make_shared<OtherClass>();
callback(o);
}
};
PYBIND11_MODULE(example, m) {
py::class_<OtherClass, std::shared_ptr<OtherClass>>(m, "OtherClass");
py::class_<N>(m, "N")
.def(py::init<N::CallbackType>(), py::arg("callback"))
.def("doit", &N::doit);
}

Doxygen: Force undeclared functions to be documented

Our C++ program has a built-in script interface and is able to run scripts in it. The scripts have access to convenience functions provided by the C++ program.
Now we would like Doxygen to create the documentation of the functions the script has access to. Such a function declaration looks like this:
void ScriptEngine::load_script(const QString &path) {
//...
/*! \fn sleep_ms(const unsigned int timeout_ms)
\brief sleeps for timeout_ms milliseconds.
\param timeout_ms
*/
(*lua)["sleep_ms"] = [](const unsigned int timeout_ms) {
//sleep(timeout_ms)
};
//more convenience functions..
//...
}
Obviously Doxygen won't include a
sleep_ms(const unsigned int timeout_ms)
into the documentation. Is there a way to to tell Doxygen to do so?
Do this:
Add the following line to your Doxyfile:
PREDEFINED = _DOXYGEN_
Make sure the ENABLE_PREPROCESSING tag in the Doxyfile is set to YES.
Put your declarations and documentation for the undeclared functions inside an #ifdef _DOXYGEN_ section.
#ifdef _DOXYGEN_
/*! \fn sleep_ms(const unsigned int timeout_ms)
\brief sleeps for timeout_ms milliseconds.
\param timeout_ms
*/
void sleep_ms(const unsigned int timeout_ms);
#endif
Don't put the above code inside a method or function such as ScriptEngine::load_script(), as you previously tried. And don't put it inside a namespace or class, unless in fact the function being declared is a member of that namespace or class.
With this method, your declarations will not create linker errors during a normal build, but will be seen by Doxygen.
See Also
http://www.doxygen.nl/manual/config.html#cfg_predefined

Extern function in interface

I am trying to declare a extern function in an interface and implementing it in a separate file in an effort to make our testharness generic.
What i want is something like this:
in_check.sv
interface in_check;
extern function bit fu_check(int num, logic state);
endinterface
in_impl.sv
interface in_impl(in_check uin_check);
function bit uin_check.fu_check(int num, logic state);
if(state) return num;
else return 0;
endfunction
endinterface
But Questasim gives me this error message:
** Error: (vsim-3787) in_impl.sv: Exported function 'uin_check.fu_check' arguments don't match those of export/extern task in interface 'in_check'.
This indicated that it should at least be possible with implicit declaration, but implicitly defined functions (i.e. extern function fu_check) gives this error message:
** Error: (vlog-13069) in_check.sv(20): near "fu_check": syntax error, unexpected IDENTIFIER.
Tasks work perfectly, and I can live with having to use an output argument. However, I would much prefer to be able to give a return value.
How can I make this work?
Bonus question: The LRM seems a bit light in info on this, is the implementation tool specific?

Systemverilog doesn't allow variable declarations after call to super.foo()?

I'm running into a weird issue working with SystemVerilog on DVT. The code snippet in question looks something like this:
class parent;
int A;
function void foo();
A = 5;
endfunction
endclass
class childA extends parent;
function void foo();
bit test_one; //Does not flag as a syntax error.
super.foo();
bit test_two; //Flags as error: Expected endfunction, found bit.
endfunction //Subsequently: Expected endclass, found endfunction
endclass //And lastly: Unexpected token: Endclass
As far as I know it is legal to call any hidden parent function using super. but this behavior is perplexing me. Can someone tell me if this is legal SV syntax? Or if not: What's the reasoning behind this?
It is illegal syntax. All variables in a task or function must be declared before any operation. See IEEE Std 1800-2012 ยง 13 Tasks and functions (subroutines)
Legal syntax is:
function void foo();
bit test_one;
bit test_two;
super.foo();
endfunction
The only exception is a begin-end block in which case the variable can be declared at the top of the begin-end block before any operation (but you can nest begin-end block). This does however limit scope access and may be less readable. So it not a good practice
function void foo();
bit test_one;
super.foo();
begin
bit test_two; // only in scope within this begin-end
begin
bit test_three; // not the same 'test_three' as below, different scope
end
begin
bit test_three; // not the same 'test_three' as above, different scope
end
// both 'test_three's are out of scope
end
// 'test_two' both 'test_three's are out of scope
endfunction
General best practice is to always declare your variables at the top. I prefer adding empty space between variable declarations and operations a visual separator; makes reading and modifying a ascetically easier.
function void foo();
bit test_one;
bit test_two;
super.foo();
endfunction

Call function in main program from a library in Arduino

I've just started making libraries in Arduino. I've made a library named inSerialCmd. I want to call a function named delegate() that is defined in the main program file, stackedcontrol.ino, after the inSerialCmd library is included.
When I try to compile, one error is thrown:
...\Arduino\libraries\inSerialCmd\inSerialCmd.cpp: In member function
'void inSerialCmd::serialListen()':
...\Arduino\libraries\inSerialCmd\inSerialCmd.cpp:32: error:
'delegate' has not been declared
After doing a bit of searching, it seemed that adding the scope resolution operator might do the trick. So I added the "::" before delegate(), now "::delegate()", but the same error is thrown.
Now I'm stumped.
You cannot and should not directly call a function in a program from a library. Keep in mind a key aspect that makes a library into a library:
A library does not depend on the specific application. A library can be fully compiled and packaged into the .a file without the existence of a program.
So there is a one way dependency, a program depends on a library. This at first glance may seem to prevent you from achieving what you want. You can achieve the functionality you are asking about through what is sometimes referred to as a callback. The main program would provide to the library at runtime a pointer to the function to execute.
// in program somwehere
int myDelegate(int a, int b);
// you set this to the library
setDelegate( myDelegate );
You see this in the arduino if you look at how interrupt handlers are installed. This same concept exists in many environments - event listeners, action adapters - all with the same goal of allowing a program to define the specific action that a library cannot know.
The library would store and call the function via the function pointer. Here is a rough sketch of what this looks like:
// in the main program
int someAction(int t1, int t2) {
return 1;
}
/* in library
this is the delegate function pointer
a function that takes two int's and returns an int */
int (*fpAction)(int, int) = 0;
/* in library
this is how an application registers its action */
void setDelegate( int (*fp)(int,int) ) {
fpAction = fp;
}
/* in libary
this is how the library can safely execute the action */
int doAction(int t1, int t2) {
int r;
if( 0 != fpAction ) {
r = (*fpAction)(t1,t2);
}
else {
// some error or default action here
r = 0;
}
return r;
}
/* in program
The main program installs its delegate, likely in setup() */
void setup () {
...
setDelegate(someAction);
...