Karsten Pedersen

There are many problems in programming that can be solved in an elegant manner via object oriented programming (OOP) including techniques such as inheritance and encapsulation. As a general purpose language, C does support OOP but it is not enforced by language constructs etc. There are also certain issues involved with using C in such a way. The most critical I have come across is memory management since destructors are not called in a deterministic manner for either the base object or the derived object. This is a shame since the simplicity of C makes it very useful for many code projects. For this reason I have been looking into ways to incorporate OOP into C in a consistent and simple manner.

First, lets have a look at how object orientation in C might be done. Consider the following struct definitions.

struct Base
{
  int baseData;
};

struct Derived
{
  struct Base* base;
  int derivedData;
};

What we are trying to do is make Derived "inherit" from Base. The Derived type contains a pointer to the Base type so that it can access the properties of the type it has "inherited" from. Unfortunately, if this is allocated (via malloc or calloc), casting it and passing into a function accepting a pointer to the Base struct will likely cause the program to crash. i.e.

void doSomethingWithBase(struct Base* base)
{
  printf("Number: %i\n", base->baseData);
}

struct Derived* derived = calloc(1, sizeof(struct Derived));
doSomethingWithBase((struct Base*)derived); // Error

This is an error because we have one type that we are casting to another in an unsafe manner and the runtime has no idea of the actual type of the data in memory that it is trying to interact with. If we contrast this with the following struct definitions.

struct Base
{
  int baseData;
};

struct Derived
{
  struct Base base; // Not simply a pointer to Base struct
  int derivedData;
};

Passing the above Derived structure into a function requiring a pointer to struct Base will now function as expected. The reasoning behind this is that when allocating space for the structure, if it is defined as having a pointer to its base structure, only enough space will be allocated for a single pointer. This exact size is platform specific but typically it is smaller than the Base struct itself. However if the derived structure contains the entire base structure (not a pointer), then enough space will be allocated for both the base structure and the derived structure. i.e.

struct Base:
[ int baseData | char* moreData | float evenMoreData ]

struct Derived (Incorrect):
[ struct Base* | int derivedData ]

struct Derived (Correct):
[ <-------- struct Base ---------------------------> | int derivedData ]

So as can be seen in the diagram, the last allocation has enough space to hold a correctly initialized Base structure, with exactly enough space left over to hold the derivedData integer.

When this is passed into a function, the data locations of struct Base are operated on in exactly the same way as if a pointer to an actual struct Base was passed into the function.

Note: As you may have guessed, the struct Base has to be the first member of the struct Derived or the data will be overwritten (and likely corrupt). Most languages do not support multiple inheritance anyway and I find that for the projects that I deal with, I rarely need the feature anyway. With some work, perhaps a struct offset can be used to specify the starting location of a member struct.

Function overriding

One powerful feature of OOP is the idea that functions can be overriden. OOP with C can do something similar using function pointers. The following listing should document the process.

// The struct Base could contain the following member
void (*update)(struct Base*)

// During the default initialization of struct Base it can be pointed to function
void BaseUpdate(struct Base* base) { ... }

// However as struct Derived is created it could reset the update function pointer
void DerivedUpdate(struct Derived* derived) { ... }

// Finally, the function can be called in a generic manner as needed
instance->update(instance);

This is pretty much it to accomplish function overriding.

Memory Management

The most critical thing when using OOP with C is to ensure that the work which would be done by the destructors in other languages is still performed. Imagine the following inheritance chain:

[ Object ]
  [ GuiObject ]
    [ ClickableGuiObject ]
      [ Button ]

If these objects only contain automatic variables (i.e they do not need to be allocated on the heap via malloc, calloc, realloc, etc) then as free is called on the final object then everything will be cleaned up. However if any of them require specific cleaning then remembering to call free() (or other cleanup functions) on each member variable of each inherited object is likely to lead to memory leaks and errors due to manually having to remember to do so. This is going to lead to difficult to maintain code.

Instead, a pretty nice way to do it would be to call ObjectFree() on any object at any level of inheritance. This is possible and by borrowing a few techniques from the C++ smart pointers can be quite clean to implement.

Imagine the following structures:

struct Image
{
  struct Object object; // Image inherits from Object.
  char* suffix; // Allocated on heap, calloc, strcat. Needs free.
};

struct PngImage
{
  struct Image image; // PngImage inherits from Image.
  SDL_Surface* data; // Allocated on heap with IMGLoad, Needs SDL_FreeSurface.
};

So, when an instance of PngImage is no longer needed, the following functions need to be called:

free(instance->suffix);
SDL_FreeSurface(instance->data);
free(instance);

If there are many places in your codebase where this needs to happen then this could be very tedious and error prone, especially if another member variable is added to a structure that also needs cleanup.

So again, the ideal solution is to be able to call something like:

ObjectFree(instance);

So what we need to do is get the base structure to know about and manage *ALL* the data of the derived types. This is not as awkward as it may first sound because in a codebase, a "struct Object" could be used to provide the base object for all objects used for OO.

Since there is a struct Image within PngImage, it effectively "inherits" from it using the inheritance system documented above. This means we can put common functions relating to memory management into the base object. So imagine the following code that demonstrates what we could do.

struct PngImage* tmp = ImageAlloc(sizeof(struct PngImage)); // Allocate the memory space and init.
tmp->data = SDL_ImageLoad("test.png";
ObjectManage((struct Object*)tmp, tmp->data, SDL_FreeSurface);
// Do something with allocated object
ObjectFree((struct Object*)tmp);

ImageAlloc is a function which simply provides a way of allocating enough space for the derived class (Including the space for the base struct) whilst still initializing the base struct correctly. I.e it might need more than everything set to zero with calloc etc... You may like to think of it as the equivalent of a constructor in C++ or Java. It may seem like boilerplate code but there is not much more than the C++ alternative.

struct Image* ImageAlloc(int size)
{
  struct Image* rtn = ObjectAlloc(size);
  rtn->suffix = calloc(1, sizeof(char));
  return rtn;
}

The SDL_FreeSurface is set as the deleter function directly after the memory is allocated for the SDL_Surface. This might not be to everyone taste but it is a great way to avoid the issue of forgetting to explicitly free the data. Most important however is that the generic ObjectFree() function can be called once which will run through all the deleter functions. This is very useful for games due to the large number of similar objects instantiated.

And this is it. Other than the inevitable generic call of ObjectFree, this code is not much longer than the C++ equivalent. When implementing, it is suggested to have a generic "struct Object" type that you begin all inheritance chains from as demonstrated above.

So to summarise, this system attempts to provide a standard object oriented design which though not claiming to be as powerful as a language with OO inbuilt like C++ or Java but good enough that all the other benefits of C can be utilized without penalty.

This is ideal for game development because there is minimal boilerplate for each object and since games architecture generally favours composition over inheritance (component entity model), this method of OOP is perfectly capable to the level of OO required.

If every logical object in a potential C project was implemented using this inheritance pattern, effectively memory management would be solved for almost everything apart from function scope. Of course a single Object could be used to handle memory in a single function but the benefits may not be worth the overhead.

I hope this exploration of inheritance and memory management in C has been interesting. At work we have begun developing some of the ideas presented and so far there have not been any major issues. If you have any questions, please feel free to ask in the comments.

Introduction

Chroots have many uses in UNIX-like operating systems and the chroot(8) command is not unique to OpenBSD. They are often used for security reasons in order to run a potentially vulnerable service in its own environment so that if it becomes compromised and an attacker manages to escalate their privileges to that of the compromised service, they are still constrained to the chroot that the service has been run in.

For my uses, chroots are great for creating small sandbox instances of an operating system where I can muck about, compile and install software and build and test OpenBSD ports. When I am done, I can simply obliterate the chroot away and replace it with another fresh one. They effectively perform the same task as virtual machines but do not produce the same overhead of an entire operating system.

It is easy to create a chroot in OpenBSD. The following steps outline the process and by the end you should have a fully up and running instance of OpenBSD to be utilized in any way you choose.

Setup

The first thing to do is decide where you want to store your created chroots within your system. This is important because if this is on an existing partition, the mount flags need to be changed within /etc/fstab so that nosuid and nodev are not set. This has a few security considerations and so it is much better to create a new partition and dedicate it entirely to chroots. These flags need to be removed since the chroot will need to be able to create device nodes and suid binaries on the partition for correct operation.

I am storing my chroots in /jails (a separate partition I created during installation) so my /etc/fstab file needed to be modified as follows:

814fb7ccfd84e045.l /jails ffs rw,nodev,nosuid 1 2

Should become:

814fb7ccfd84e045.l /jails ffs rw 1 2

Now that the partition is set and has been remounted with the new flags (an easy way to do this is by just restarting the machine), I create a new folder in it which will contain the new chroot. Since my intended use for it is often to function as a build sandbox, I will call mine sandbox.

# cd /jails
# mkdir sandbox
# cd sandbox

Now we want to construct the base file layout for OpenBSD. This is where using an operating system with simple base packages makes this easier since we do not need to rely on a package manager for this step. Instead we simply extract the small number of archives containing the entire base system. These files are found on the OpenBSD FTP or on the install CD so we mount the CD with the following commands

# mount -t cd9660 /dev/cd0a /mnt

And then we extract them into our current location (the sandbox directory). I also suggest copying these archives to your hard disk for future chroot setups.

# tar -xzf /mnt/5.5/i386/base55.tgz
# tar -xzf /mnt/5.5/i386/etc55.tgz
# tar -xzf /mnt/5.5/i386/comp55.tgz
# tar -xzf /mnt/5.5/i386/xbase55.tgz
# tar -xzf /mnt/5.5/i386/xshare55.tgz
# tar -xzf /mnt/5.5/i386/xetc55.tgz
# tar -xzf /mnt/5.5/i386/xfont55.tgz
# tar -xzf /mnt/5.5/i386/xserv55.tgz

Note that I also extracted the Xenocara (x*.tar.gz) packages. This is because OpenBSD recommends always installing them as part of base even if they are not used. Since I intend to build software in the chroot, I also needed them otherwise the ports system requires additional steps to get working.

At this point I also download and extract the ports tarball. This is optional depending on what you intend to do with the chroot.

# cd usr
# wget ftp://ftp.openbsd.org/pub/OpenBSD/5.5/ports.tar.gz
# tar -xzf ports.tar.gz
# cd ..

In order for the programs in the chroot to work properly, it needs the /dev folder to be populated. You will notice that the MAKEDEV script has been extracted as part of the base. All we need to do is run it like so.

# cd dev
# ./MAKEDEV all
# cd ..

Once this is done, I copy across the /etc/resolv.conf file from the host so that I can correctly resolve DNS entries from within the chroot.

# cp /etc/resolv.conf etc/

We will finally use the chroot command to call ldconfig within sandbox so to ensure that the /var/run/ld.so.hints file is correctly generated. This is required so that any program that we run in the chroot that utilizes a shared library will be able to find it.

# chroot /jails/sandbox ldconfig /usr/lib /usr/local/lib /usr/X11R6/lib

Usage

Now we are ready to use the chroot command again to actually enter the newly created instance. I also specify su -l so that the correct environment is set for the superuser of that chroot.

# chroot /jails/sandbox su -l

Congratulations, the chroot is now set up and ready for use. If you plan on using it to build ports, then you can immediately start doing so as follows.

# /usr/ports/net/curl
# make package clean

From here, you can do a lot of damage without adversely effecting the host install. Be aware though that it is possible for a malicious user or program to break out of this setup. This is quite unlikely to happen for my purposes but if you are concerned about this, you might want to look into similar alternatives such as Jails on FreeBSD, Zones on Solaris and WPARs on AIX.

Additional

One thing that you may find useful is to script the above setup steps. This will allow you to potentially setup and tear down chroots quickly as needed. Luckily almost all the steps (apart from perhaps setting up the partitions) are very straight forward to add to a shell script.

Another thing to note is that OpenBSD comes with Xephyr as part of the base system. This tool makes it very easy to run X11 applications from within the chroot. Once Xephyr is running, executing the following command from within the chroot should open up an xterm within the Xephyr window.

# DISPLAY=:1 xterm

I hope you have found this brief startup guide on how to setup a chroot useful. Please feel free to leave a comment if you notice anything to be incorrect or if you are running into any problems that you would like me to cover.

At work I have been busy developing the server side component of our top secret sports game. Since the production server is to be running on OpenBSD, I decided it would be a good idea to actually develop it using the same operating system.

One slight snag was that OpenBSD is no longer supported by Perforce, the version control we use at work. The last version of Perforce available for OpenBSD was for OpenBSD 3.1. Unfortunately loads of stuff has changed since then (in both OpenBSD and Perforce) so this binary no longer works. This is a little annoying but since Perforce is pretty great to work with, I decided to look for ways to get around this issue. Luckily, I found a solution.

OpenBSD for i386 still provides Linux binary compatibility in the GENERIC kernel (compat_linux(8)) and the p4 command line binary works with it. Since I am mainly developing the software on OpenBSD using ssh, tmux and vim, the command line binary is all I needed anyway.

The following steps were required to get this to work.

First I enabled Linux compatibility using sysctl.

# sysctl kern.emul.linux=1

I then set this to be persistent across reboots by uncommenting the following line in /etc/sysctl.conf.

kern.emul.linux=1

Finally I installed the fedora_base package (This actually calls the same sysctl command in the first step as well).

# pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/5.5/packages/i386/fedora_base

This package adds a self contained Linux file hierarchy inside /emul/linux containing various libraries that might be needed by the Linux binaries.

With these steps complete, all that I then needed to do was download the x86 Linux p4 binary (you might want to download the latest version) from the Perforce website.

$ curl -O http://filehost.perforce.com/perforce/r14.1/bin.linux26x86/p4

Then I copied it to /usr/local/bin and set the permissions to executable.

# cp p4 /usr/local/bin
# chmod +x /usr/local/bin/p4

And that was it. The p4 command could then be used as normal.

$ export P4PORT=perforce.[host].com:1666
$ export P4USER=[username]
$ export P4PASSWD=[password]
$ export P4CLIENT=[client]
$ p4 workspace
$ p4 sync
etc...

So this all works great for me. There are a few limitations however. The Linux binary compatibility only works on i386 (not amd64) builds of OpenBSD. The Linux binary compatibility also does not see much development or improvements nowadays so is still quite incomplete. I don't know how much longer it is going to remain part of the OpenBSD kernel. I was pretty surprised to see it in the GENERIC kernel in the first place.

Out of pure curiosity I attempted to run the p4v GUI client for Perforce on OpenBSD using Linux compatibility. It got up to the login window which was fully working, however after logging in and as soon as the main window appears the whole program would segfault. I didn't look into it much further since debugging tools in Linux compatibility are quite lacking but... Darn, So close! ;)

Perforce provides another, more official solution called GitFusion which should allow me to use git on OpenBSD to effectively utilize to the Perforce repo. However, even though it sounds pretty awesome I have yet to have a play with it. It also does not seem to support streams yet which would be a bit of an issue for this project.

A brief overview of Emscripten

Emscripten is an extremely interesting project that allows C and C++ developers to compile their code into Javascript which can then run in a web browser. It can also be instructed to produce an entire .html file complete with a drawing canvas or even a WebGL rendering context. This is fantastic because it allows porting of existing applications to the web quickly and without requiring a rewrite of the code. Some notable examples are Epic Game's Unreal Engine, ScummVM, SuperTux and JS-VBA-M (A gameboy advance emulator).

For more info, visit
https://github.com/kripken/emscripten

Getting Started on FreeBSD

• First, install the lang/clang port. Emscripten uses this to generate an LLVM output which it then converts to Javascript. As of writing, this is version 3.2 which is the version Emscripten requires. There are usually different versions within the ports collection so have a look around for the correct matching version.
• Next, install www/node. Emscripten is written in Javascript and so requires this to run. This needs to be version 0.8 or above.
• Install lang/python. Emscripten uses this for it's build environment. This needs to be version 2.7 or above.

Now simply download the latest Emscripten snapshot and extract to a writable directory (for example, I extracted mine to /usr/home/kpedersen/emscripten). Now add that directory to your path and execute `emcc`. This will possibly output some error messages but will also generate a file called ".emscripten" in your home directory. Open that file in a text editor and ensure that EMSCRIPTEN_ROOT, LLVM_ROOT, PYTHON and NODE_JS paths are correct. Note that LLVM_ROOT should actually point to the bin directory (i.e /usr/local/bin) or it wont work.

Once this is done, now make a simple test program in C or C++ to output hello world and you can then compile with:

For C

emcc main.c -o index.html

For C++

em++ main.cpp -o index.html

You should notice an index.html file now exists in your current directory. Open this with a web browser and you should see hello world written in the console.
If your application uses SDL.h or GL/gl.h, you will see the output image in the space just above the console.

How awesome is that!

RAII (Resource Acquisition Is Initialization) is an incredibly important technique in C++ (D and Ada) which helps ensure that memory leaks are prevented. Without it the developer would have to manually free up used memory once it is no longer needed which could then cause issues with exception safety. RAII is discussed in detail in [The C++ programming Language, Bjarne Stroustrup] so I will not go into too much depth here. The idea is that the destructors of all objects residing on the stack are called as they go out of scope (perhaps due to propagation of an exception during stack unwinding). These destructors then contain any important cleanup code such as stopping a thread, closing a file etc...

In order to take advantage of RAII, any C libraries must be wrapped in C++ classes first. An example of which would be GTK+ which provides an official C++ binding called gtkmm. I have also found that I needed to do the same with the Motif library in order to safely use it with C++ in the OpenCDE project (motifmm). This was a large amount of work and is nowhere near complete. There is also a downfall in that since other developers have started to join the project and some are more experienced with C than C++ or visa versa, it is quite awkward for code reuse to take place. For example a C++ .ini parser can only be used by C++ developers or a C .ini parser can only safely be used by the C developers. What I have been looking for is a way that both the C and C++ developers can correctly use the same code.

Looking at two ideas which are slightly similar to what I require, The C++ auto_ptr template class and the GNU C Compiler's extension of the cleanup variable attribute. The auto_ptr is one of the earliest and simplest of C++ smart pointers that allow for RAII to take place on objects stored on the heap or that use file resources etc... However it cannot be used with C code at all so the following would not make any sense.

std::auto_ptr<FILE> file;

file.reset(fopen("example.txt", "r"));
// Prepare for a crash!

This compiled and ran but results in undefined behavior. What would happen behind the scenes is that delete would be called on our FILE pointer which is obviously incorrect and should have been fclose(). It probably wouldn't work even if free() correctly cleans up the memory since delete and free() are generally not interchangeable in the majority of C++ compilers (I have only seen it work on a few select versions of GCC). So it seems that the smart pointer needs a way of explicitly knowing how to clean up the data of the contained pointer rather than just making an (often incorrect) assumption.

This brings us onto the GNU C Compiler extension.

#define RAII_VARIABLE(vartype,varname,initval,dtor) \
    void _dtor_ ## varname (vartype * v) { dtor(*v); } \
    vartype varname __attribute__((cleanup(_dtor_ ## varname))) = (initval)

void example_usage()
{
  RAII_VARIABLE(FILE*, logfile, fopen("logfile.txt", "w+"), fclose);
  fputs("hello logfile!", logfile);
}

Though implemented with a slightly complex macro and not portable between C compilers, this does work. The important thing to note is that an fclose() function pointer has been passed in so the cleanup method is explicitly stated. If this can be implemented with a C++ template class, it will allow our new smart pointer class to work with most C++ compilers available rather than being a compiler specific extension.

I have implemented a "toy" version of a template class which should demonstrate the idea discussed above. It has been kept deliberately simple and as such does not throw any kind of exception when the reset() fails if fopen() returns NULL)

#ifndef C_PTR_H
#define C_PTR_H

#include <iostream>

template<class T, class R> class c_ptr
{
private:
  T t;
  R (*func)(T);
 
  void clean()
  {
    if(func != 0 && t != 0)
    {
      (*func)(t);
      t = 0;
      func = 0;
    }
  }
 
public:
  c_ptr()
  {
    t = 0;
    func = 0;
  }
 
  ~c_ptr()
  {
    clean();
  }
 
  void reset(T t, R (*func)(T))
  {
    clean();

    this->t = t;
    this->func = func;
  }
 
  T get()
  {
    return t;
  }
};

#endif

With the above template class, an example of working with files the "C way" rather than std::ofstream is demonstrated.

c_ptr<FILE*> file1;
c_ptr<FILE*> file2;

file1.reset(fopen("example.txt", "w+"), fclose);

if(file1.get() == NULL)
{
  return;
}

file2.reset(fopen("test.txt", "w+"), fclose);

if(file2.get() == NULL)
{
  // No need to clean up file1
  return;
}

fputs("hello world!", file1.get());
// No need to do any cleanup

With this, as the smart pointer container (c_ptr) goes out of scope, fclose is called on the contained pointer rather than the more generic free() or delete. Note that a FILE* pointer is explicitly specified as the template argument rather than FILE, this is because sometimes the data is not handled via a pointer such as an OpenGL texture (GLuint) or a sys/socket (int).

The above c_ptr implementation will need improvements such as for cleanup functions that require more than one parameter (XtDestroyWidget(XtDisplay(widget), widget)). This is made even worse because the secondary parameter (XtDisplay*) can only be derived from the primary parameter (Widget, the one that needs cleanup) but that doesn't yet exist when passing in the cleanup function and parameters. (Luckily XtDestroyWidget() only requires one parameter, I had to lie a little bit to show the worse case scenario).

After my initial research I found that std::function could handle most of this for me and is also part of the C++ standard (thus the std namespace). Unfortunately it must have been a new addition to the standard since it didn't seem to exist on my older version of g++ (not even in the tr1 namespace). Since I tend to only use features that are in the lowest common denominator of platforms (and because I like to hack on code ;), I decided to write my own simple alternative.

Function pointers in C++ are seemingly more complex than their C counterparts because the class instance needs to be known in order for the callback to work. I decided to get around this issue by introducing templates so the type of the “callback class” could easily be specified. When working with templates, it quickly began getting messy since the template type had to keep being specified every time the function pointer class was being passed around in the application logic. So to get around this I inherited from a more generic Function class. This can be seen in the code below.

Function.h

So now a GUI component such as a button can contain a fully encapsulated function pointer for it's onClickEvent(). This can also be put inside an auto_ptr container to prevent any memory leaks. The only real work now is making sure that the class containing the method that the function points to is not deleted when being called but if the software has correct logic, this will be very unlikely anyway.

In short, I no longer need be jealous of the callback systems found in javax.swing or Windows.Forms since although done quite differently, my GUI library should hopefully be as straightforward to use in this respect.

From the code above it is also trivial to add a template class similar to GenericFunction which can take a void* parameter so the caller (i.e Button) can also be passed when calling the function pointer's function, so it is possible for the programmer to determine in code, which button triggered the callback.

Before I start any OpenGL project, past experience has always taught me to make sure that I can get the basics to compile on my current system before trying to do anything clever. I have once spent countless hours trying to debug an OpenGL project only to find that I was using an old buggy version of FreeGLUT (Which has since improved greatly!). Below is a short code listing of a very basic OpenGL application.

In order to get this to compile we need to link it with 3 libraries: libGL, libGLU and libglut

This code can be compiled by issuing the following command:-

Now when ./simple is run a window should appear with a rotating teapot.

If this has worked, then congratulations on creating your simple OpenGL application, now you can progress onto the fun stuff!

Hello World!,

This blog should hopefully prove to be an interest to developers who enjoy working with C++ and OpenGL since many of my blog entries are intended to discuss some of the highlights experienced when working with these technologies for my University dissertation.

Since I am an huge fan of unix-based operating systems, the majority of topics will be biased towards the FreeBSD operating system as the target platform but almost all of the code I develop is intended to be cross platform so most things should seem familiar regardless of platform.

Hopefully someone might find something of use in my posts.

Best Regards,

Karsten Pedersen