Swig and Lua: how to map Lua file to FILE* - lua

I have a C function that takes FILE* as an argument and I'd like to use this function in Lua, passing Lua file. I guess I need a %typemap for this. How to write it?
(I just started learning Lua).

Here is the solution that I finally came up with.
In Lua source, in liolib.c, there is a function FILE *tofile (lua_State *L), which converts Lua file to C FILE*, but it's not a part of the API. I modified it a bit to make a typemap:
%typemap(in) FILE * {
FILE **f;
if (lua_isnil(L, $input))
$1=NULL;
else {
f = (FILE **)luaL_checkudata(L, $input, "FILE*");
if (*f == NULL)
luaL_error(L, "attempt to use a closed file");
$1=*f;
}
}
This typemap accepts also nil, because I needed a way to pass NULL to the C function.

You're using SWIG to generate Lua bindings for your C code? Why not use the Lua C API directly, or if you can use C++, Luabind? I think either of those would be better than trying to make it work with SWIG, unless you've got a strong attachment to SWIG already.

There's no easy way to do what you're asking.
The Lua File class interface abstracts the underlying implementation. You cannot simply typemap it. You can, however, create a C proxy that wraps FILE operations you need and create an instance of this proxy in Lua using SWIG. You can then generate a typemap to convert a FILE* to a wrapper proxy instance.
Something like:
class MyFileProxy {
private:
FILE* fp;
public:
MyFileProxy(FILE* fp);
MyFileProxy(const char* path);
FILE* GetFilePointer();
Seek(...
In SWIG the binding is simply:
%module "MyFile"
%{
#include "MyFileProxy.h"
%}
// Tell SWIG how to use a proxy for functions that take a FILE*
%typemap(in) FILE*
{
void* tmp = 0;
SWIG_ConvertPtr(L,$argnum,(void**)&tmp,$1_descriptor,1);
if (tmp)
{
MyFileProxy* proxy = (MyFileProxy)tmp;
arg$argnum = proxy->GetFilePointer();
}
}
// Tell SWIG how to create a proxy when returning FILE*
%typemap(out) FILE*
{
MyFileProxy* pResult = new MyFileProxy($arg);
SWIG_NewPointerObj(L, pResult, $1_descriptor, 1);
}
%include "MyFileProxy.h
}
You won't be able to use io:File directly, however.

Related

Choosing unique names for luaL_newmetatable

I'm writing a Lua library which registers some metatables using luaL_newmetatable(). Since other libraries might do that as well, I'd like to ask what is a good strategy to avoid having the same name used twice. I was thinking about using a reverse DNS name like com.mydomain.mylibrary which should be pretty safe I guess. However, I'd like to ask if there maybe is a better or standard way of choosing unique names for libraries using luaL_newmetatable().
I like use lightuserdata with pointer to string.
#define LCURL_EASY_NAME LCURL_PREFIX" Easy"
static const char *LCURL_EASY = LCURL_EASY_NAME;
It just requires simple functions to use it.
int lutil_newmetatablep (lua_State *L, const void *p) {
lua_rawgetp(L, LUA_REGISTRYINDEX, p);
if (!lua_isnil(L, -1))
return 0;
lua_pop(L, 1);
lua_newtable(L); /* create metatable */
lua_pushvalue(L, -1); /* duplicate metatable to set*/
lua_rawsetp(L, LUA_REGISTRYINDEX, p);
return 1;
}
Similar for get/set. Checkout e.g. my Lua-cURL library.
I would use a string that describes what is in the "object" as this string is output in Lua error message eventually:
e.g. if the metatable is named "database connection":
stdin:1: bad argument #1 to 'status' (database connection expected, got no value)
If you use a UUID, nobody can make sense of the output.

How to exculde build-in / system function during function analysis by clang libtooling

I'm trying to analyze functions by using clang libtooling.
Here is the source code that I want to analyze:
#include <stdio.h>
int main(){
int a = 100;
printf("a==%d", a);
}
when I run my tool to get all the function decl in above files, I found there are a lot of build-in / system functions, like:
decls:
_IO_cookie_init
__underflow
__uflow
__overflow
_IO_getc
_IO_putc
_IO_feof
_IO_ferror
_IO_peekc_locked
_IO_flockfile
_IO_funlockfile
_IO_ftrylockfile
_IO_vfscanf
_IO_vfprintf
_IO_padn
_IO_sgetn
_IO_seekoff
_IO_seekpos
_IO_free_backup_area
remove
rename
renameat
tmpfile
tmpfile64
tmpnam
tmpnam_r
tempnam
fclose
fflush
fflush_unlocked
fcloseall
fopen
(I think they are introduced by the header file "stdio.h" )
my question is:
How can I get rid of all these built-in/system functions from the "stdio.h" file, or other (system) header files?
Thanks in advance!!!
When you visit a function, check if its location (startLoc or endLoc) is in system header using SourceManagers api 'isInSystemHeader(loc)'
e.g.:
Bool VisitFunctionDecl(FunctionDecl * D)
{
If(sourceManager.isInSystemHeader(D->getLocStart()))
return true;
}
Thanks,
Hemant

Call libc function from JNA

I use a C library from Java through JNA and one function does not flush properly (since the output appear all at once on program end). I have tried Java side System.out.flush(); with no luck.
In brief, I would like to call C fflush(stdout) from Java. With JNA already there (thus would prefer if no additional library) and without C to write.
I am aware of JNA Library mapping as in this question but that seems overkill to me.
The JNA library wrapping way code is actually not so heavy (at least for the flush all behavior).
protected interface CLibrary extends Library
{
static CLibrary clib = (CLibrary) Native.loadLibrary ("c", CLibrary.class);
int fflush (Pointer stream);
}
/* ... */
CLibrary.clib.fflush (null);
JNA also offer late binding method and these oneliners will do what you want
NativeLibrary.getInstance ("c").getFunction ("fflush").invokeInt (new Object[]{0});
// even shorter
Function.getFunction ("c", "fflush").invokeInt (new Object[]{0});
The tedious part comes when you want to limit flushing to stdout. You have to deal with vendor-specific code (stdout is either defined as a macro expanding to an array, Amtel avr-libc, to a function call, Microsoft msvcrt, or a pointer in GNU libc).
For the libc, you might use (two lines for legibility)
Pointer stdout = NativeLibrary.getInstance ("c").getGlobalVariableAddress ("stdout").getPointer (0);
Function.getFunction ("c", "fflush").invokeInt (new Object[]{stdout});
Adding this answer for Win32 / Win64 users, complementing FabienAndre's for GNU libc.
Selectively flushing the stdout stream calling the system's c library's fflush method via jna is hard and cumbersome. As FabienAndre already mentioned, it is difficult to get a hold of the stdout macro definition. For msvcrt (the Win32 / Win64 C library) it is defined via a function call to __iob_func(); the latter returning a pointer to an array of FILE structures. At index 0 is stdin, index 1 is stdout and index 2 is stderr. So for flushing stdout you even need to know the size of the FILE structure, of course, it is different for Win32 and Win64 ...
The following example is tested under Win64 but ought to work under Win32. It was inspired by the thread JNA solutions to catch stdout/stderr of DLL.
import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.Platform;
import com.sun.jna.Pointer;
public class JnaTest {
public interface CLibrary extends Library {
CLibrary INSTANCE = (CLibrary) Native.loadLibrary("msvcrt" , CLibrary.class);
Pointer __iob_func();
void printf(String format, Object... args);
int fflush (Pointer stream);
}
public static void main(String[] args) {
int sizeOfFileStructure = Platform.is64Bit() ? 48 : 32;
Pointer stdout = CLibrary.INSTANCE.__iob_func().share(sizeOfFileStructure);
CLibrary.INSTANCE.printf("Hello, World\n");
CLibrary.INSTANCE.fflush(stdout);
}
}

Luabind calling convention issues

I am having an issue with Luabind that I am unsure of how to fix without some over-simplified solution.
Luabind appears to only allow binding to functions using the __cdecl calling convention. In my current project all of the functionality exposed to extensions/plugins is exposed using __stdcall. This leaves me unable to bind the exposed objects directly and instead I have to make wrappers for the objects exposed. This would be fine but there are a lot of objects that would need to be wrapped.
For example, an object can look like this:
struct IObject
{
void __stdcall SomeFunc1( void );
void __stdcall SomeFunc2( const char* );
};
struct IObjectContainer
{
IObject* __stdcall GetObject( int );
IObject* __stdcall GetObject( const char* );
};
struct IObjectCore
{
IObjectContainer* __stdcall GetObjectContainer();
};
I don't have the option of changing the entire projects calling convention currently so I am seeing if someone has a solution to perhaps patch Luabind to work with __stdcall functions. I am not the best with templates and with boost things, so I'm personally unsure where to even start trying to add the ability to use __stdcall functions.
For reference, I am using:
Lua 5.1.4
Luabind 0.9.1
VS2010
Both Lua and Luabind are stock latest versions of their rev. (Not using Lua 5.2 for project restriction reasons, but if there is a __stdcall fix for 5.2/Luabind I will gladly take that as well.)
I could only find a fix for a very old version of Luabind to do this but the patch floating on the net still for that does not line up with the current Luabind code at all.
If there is any other information needed feel free to ask.
Sadly due to inactivity and no further answers from more searching I spoke with the project developer and have gotten the entire project stripped of __stdcall. So the bindings all work fine now via __cdecl. Not the route I wanted to take but things are working as planned now.
I faced the exact same problem when binding OpenGL (with GLEW functions) to Lua, and solved it using variadic templates.
Now if the function is global and you know its address in compile time, you can be good with something like this:
template<typename Signature>
struct wrap_known;
template<typename Ret, typename... Args>
struct wrap_known<Ret __stdcall (Args...)> {
template <Ret __stdcall functor(Args...)>
static Ret invoke(Args... arguments) {
return functor(arguments...);
}
};
// I know using macro is generally a bad idea but it's just shorter
#define wrap(f) wrap_known<decltype(f)>::invoke<f>
and then, when binding, use the macro like this:
luabind::def("Clear", wrap(glClear)),
luabind::def("Vertex4f", wrap(glVertex4f))
However, in your case, we have a bunch of member functions and not globals like above.
Here is the code for wrapping member functions with __stdcall calling convention:
template<typename Signature>
struct wrap_mem;
template<typename Sub, typename Ret, typename... Args>
struct wrap_mem<Ret(__stdcall Sub::*) (Args...)> {
template <Ret(__stdcall Sub::*functor) (Args...)>
static Ret invoke(Sub* subject, Args... arguments) {
return (subject->*functor)(arguments...);
}
};
#define wrap_member(f) wrap_mem<decltype(f)>::invoke<f>
Use it like this:
struct A {
int __stdcall my_method(double b) {
return 2;
}
};
// ...
luabind::class_<A>("A")
.def("my_method", wrap_member(&A::my_method))
Sometimes, however, you are not that lucky to know the function's address in compile time, and this happens with GLEW for example. For functions like glUniform*f, glGetUniformLocation, the "wrap" macro will not work, so I made another version for wrapping functions known at runtime:
template<typename Signature>
struct wrap_unknown;
template<typename Ret, typename... Args>
struct wrap_unknown<Ret (__stdcall*) (Args...)> {
template <Ret (__stdcall** functor)(Args...)>
static Ret invoke(Args... arguments) {
return (**functor)(arguments...);
}
};
#define wrap_ptr(f) wrap_unknown<decltype(f)>::invoke<&f>
(if above code scares you, it is actually a good sign)
Now you can bind GLEW functions like this:
luabind::def("Uniform4f", wrap_ptr(glUniform4f)),
luabind::def("GetUniformLocation", wrap_ptr(glGetUniformLocation))
Just don't ask me to write another version for binding pointers to members known at runtime :)
If you don't want to use C++11 for some reason, here you can find out how to pass function arguments and return value as template parameters in C++03.

LuaBind and package.loadlib

I'm trying to go through the tutorial with luabind here, http://www.rasterbar.com/products/luabind/docs.html, however i'm having trouble loading the library. I'm currently using version 5.1 of lua, so I believe I would use package.loadlib instead of loadlib. I made a simple dll which is this:
#include <iostream>
#include <luabind\luabind.hpp>
void greet()
{
std::cout << "Hello world!\n";
}
extern "C" int init(lua_State* L)
{
luabind::open(L);
luabind::module(L)
[
luabind::def("greet", &greet)
];
return 0;
}
This builds just fine. However I get an error in lua when I try to run this code:
package.loadlib("LuaTestLib.dll", "init")
greet()
It states that greet is nil. How do I load the functions from the dll properly?
From the first two sentences of package.loadlib's documentation:
Dynamically links the host program with the C library libname. Inside this library, looks for a function funcname and returns this function as a C function.
(emphasis added)
This doesn't execute funcname. It simply returns it as a function for you to call. You still have to call it:
package.loadlib("LuaTestLib.dll", "init")()

Resources