Simplified Wrapper and Interface Generator
SWIG (simplified wrapper and interface generator) is a software development tool that connects programs written in C, C++ and Objective-C with a variety of high-level programming languages. It is often used with common scripting languages such as Perl, Python and Tcl/Tk. In addition, it has been extended to include languages such as Java, Eiffel and Guile.
SWIG is used to create high-level interpreted programming environments for systems integration, and as a tool for building user interfaces and testing. It is distributed as open source and can be downloaded from http://www.swig.org/.
In the following sections, I will discuss some of SWIG's features and my personal experience with it as a testing engineer at Zero Knowledge Systems (http://www.zeroknowledge.com/) for the Freedom Software.
At work, I have to test e-mail, web, IRC, FTP, proxy servers and TELNET clients. My machine is a Pentium powered by a 266MHz processor running Red Hat Linux with 128MB of RAM. My responsibilities include testing the source code currently being developed—hundreds of thousands of lines of code in a mission-critical system, with no room for errors. Given that “the strength of a security system is the strength of its weakest link”, there was no place for flaws. The code cannot be tested manually, because of the distributed architecture of client and servers. Thus, there was an urgent need for an efficient tool that would automate testing procedures. This tool had to be platform-independent and compliant with both C and C++.
Shopping around, I learned about SWIG from its web page. The source can be easily compiled for Linux; it is about 2MB in size. SWIG is multi-platform, i.e., there is no need to duplicate test procedures for Linux and Windows; it supports C and C++; and it can be integrated into MSVC++ (Microsoft Visual C++). SWIG proved to be the perfect tool.
SWIG accepts as input an ANSI C-like interface file that describes the functions and objects constituting the program to be tested. The interface file can also include SWIG directives and documentation. SWIG wraps the functions in another C program. When both of these programs (the source code and the wrapped source code) get compiled, SWIG creates a library file that can be called from the Tcl shell.
The Program: start by writing your C program to be tested. One thing to note is you have to modify the name of the “main” function. Listing 1 is an example of a C program.
Interface file: in order to allow SWIG control over this program, we have to write an “interface file”. An interface file for our C functions might look like the one in Listing 2.
Build a Tcl module: at the prompt, type the following:
swig -tcl8 my_interface.iThis command will create a Tcl 8.0-compliant library.
Compile wrappers for Tcl using the commands
gcc -fpic -c example.c example_wrap.c\ -I/usr/local/include gcc -shared example.o example_wrap.o\ -o example.so
Call the Tcl shell by typing tclsh.
Load the example.so library with the command
load ./example.so example
get_time Sun Feb 11 23:01:07 1996
SWIG helped me a lot, due to the flexibility of function calling it provides. The company had a secure mail system to be tested. In this system, all e-mail messages go through several servers before they reach their final destination, and they are encrypted each time they pass through a new routing server.
My approach toward testing this environment was to write an e-mail generator program in C which I called GenerateMail. GenerateMail accepts several options such as the number of To, CC and Bcc copies, the number of file attachments, etc. It produces a file ready to be piped to Sendmail.
A typical GenerateMail run would be something like:
tclsh generate_mail -Attachments 3 -CC 2\ -output file msg.txt tclsh send_mail msg.txt
The first line creates an e-mail message file. The message has three target addresses and two carbon copies. Three binary files were attached as MIME attachments. By default, GenerateMail uses bitmaps that are in its current directory.
The second line calls Sendmail with the appropriate options to accept that mail message and send it on to the wire. Doing that, it was easy to generate a large number of mail messages. In addition, comparing the source and destination message checksums was very easy with the help of SWIG.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide