search

LaKabane / libtuntap

The portable Tun/Tap devices configuration utility
193 stars 63 forks source link

C++ bindings #48

Open marek22k opened 9 months ago

marek22k commented 9 months ago

Hello,

when I was working with the libtuntap in C++, I noticed a few things about the wrapper: There are two different classes for tun devices and for tap devices. This is very inconvenient with memory allocation, since C/C++ has static typing. However, if you want to decide at runtime (e.g. based on configuration files) whether to use Tun or Tap, this is unfavorable. One way to solve this would be to use a common parent class. However, since only the call to tuntap_start changes, a variable in the constructor makes more sense in my understanding. Furthermore, there was no way to specify the tunnel ID. Furthermore, there was faulty error handling. In my tests (it was my fault) I had the case that the interface name could not be set. This was not reported back. Instead, the function simply logged an output and pretended that everything was OK.

This is my attempt to improve these points. I also made a few beauty corrections. I also added an argument validation, which recognizes very simple errors and then throws an exception.

marek22k commented 7 months ago

If nothing speaks against it, perhaps the PR can be merged?

marek22k commented 7 months ago

When I was developing a program, I asked on Stackoverflow. In the example, I used this libtuntap library, among others. Someone there kindly noted that if there is an error in the constuctor, the destructor is never called and a memory leak occurs. I have now adapted the bindings as suggested on Stackoverflow so that a unique_ptr is used.