Converting a swift object to a pointer (and back)

Sometimes it is necessary to convert a swift object to a pointer. This is required in situations, for example, where you need to pass a swift object to a C function that takes a void * (AKA UnsafeMutableRawPointer) parameter. Getting a pointer to a swift class is fairly simple, although it can take a while to find the correct syntax. The following code snipper will convert a Swift NSArray instance to an UnsafeMutableRawPointer, and back to a NSArray without changing the retain count. If you paste the code into a playground, it will print "same array".

	let nsarray = NSArray()
	let nsarrayPointer = Unmanaged.passUnretained( nsarray ).toOpaque()
	let nsarray2 = Unmanaged<NSArray>.fromOpaque( nsarrayPointer ).takeUnretainedValue()
	if( nsarray === nsarray2 )
	{
	print( "same array" )
	}

view raw SwiftPointerConversion.swift hosted with ❤ by GitHub

A simple libpcap example for live packet captures

libpcap is an extremely useful library for, among other things, capturing network packets in realtime. The library has a lot of options, so I put together a simple example of how to do a packet capture. Depending on your platform, libpcap may return packets in "chunks". In other words, the kernel may wait until a certain number of packets have been received, or a certain amount of time has elapsed, before notifying your application that data is available. In this example, since I want to be notified as soon as a packet is available, I attempt to turn off those behaviors using the pcap_set_timeout() and pcap_set_immediate_mode() APIs. These APIs may behave differently across various platforms.

	#include <stdio.h>
	#include <stdlib.h>
	#include <pcap/pcap.h>
	#include <net/ethernet.h>
	pcap_t * CreatePcapForInterface( const char * interfaceName )
	{
	char errbuf[PCAP_ERRBUF_SIZE];
	int success = 0;
	// Create a packet capture handle for the specified interface
	pcap_t * pcap = pcap_create( interfaceName, errbuf );
	if( pcap == NULL )
	{
	fprintf( stderr, "Unable to create pcap for interface %s (%s).\n", interfaceName, errbuf );
	goto exit;
	}
	// Deliver packets as soon as they arrive. See the pcap man page for more info.
	if( pcap_set_timeout( pcap, 1 ) != 0 )
	{
	fprintf( stderr, "Unable to configure timeout.\n" );
	goto exit;
	}
	// When immediate mode is enabled, reads return immediately upon packet reception.
	// Otherwise, a read will block until either the kernel buffer becomes full or a timeout occurs.
	if( pcap_set_immediate_mode( pcap, 1 ) != 0 )
	{
	fprintf( stderr, "Unable to configure immediate mode.\n" );
	goto exit;
	}
	// Activate packet capture handle to look at packets on the network
	int activateStatus = pcap_activate( pcap );
	if( activateStatus < 0 )
	{
	pcap_perror( pcap, "Activate failed" );
	goto exit;
	}
	// Set ethernet link-layer header type
	if( pcap_set_datalink( pcap, DLT_EN10MB ) )
	{
	pcap_perror( pcap, "Set datalink failed" );
	goto exit;
	}
	success = 1;
	exit:
	if( success == 0 )
	{
	if( pcap )
	{
	pcap_close( pcap );
	pcap = NULL;
	}
	}
	return pcap;
	}
	void MonitorPcap( pcap_t * pcap )
	{
	int pcapFD = pcap_get_selectable_fd( pcap );
	if( pcapFD < 0 )
	return;
	fd_set allFileDescriptorSet;
	FD_ZERO( &allFileDescriptorSet );
	FD_SET( pcapFD, &allFileDescriptorSet );
	for( ;; )
	{
	fd_set readFileDescriptorSet = allFileDescriptorSet;
	int readyCount = select( pcapFD + 1, &readFileDescriptorSet, NULL, NULL, NULL );
	if( readyCount < 0 )
	break;
	if( FD_ISSET( pcapFD, &readFileDescriptorSet ) )
	{
	struct pcap_pkthdr * pcapHeader;
	const u_char * packetPtr;
	int packetCount = pcap_next_ex( pcap, &pcapHeader, &packetPtr );
	if( packetCount < 0 )
	break;
	printf( "Got %u byte packet:\n", pcapHeader->caplen );
	if( pcapHeader->caplen >= sizeof( struct ether_header ) )
	{
	struct ether_header * eh = (struct ether_header *)packetPtr;
	printf( "\tdst=%02x:%02x:%02x:%02x,%02x:%02x src=%02x:%02x:%02x:%02x,%02x:%02x, type=0x%04x\n",
	eh->ether_dhost[0], eh->ether_dhost[1], eh->ether_dhost[2],
	eh->ether_dhost[3], eh->ether_dhost[4], eh->ether_dhost[5],
	eh->ether_shost[0], eh->ether_shost[1], eh->ether_shost[2],
	eh->ether_shost[3], eh->ether_shost[4], eh->ether_shost[5],
	ntohs( eh->ether_type ) );
	}
	}
	}
	}
	int main()
	{
	pcap_t * pcap = CreatePcapForInterface( "en0" );
	if( !pcap )
	exit( EXIT_FAILURE );
	// This could be done on a separate thread, or as a part
	// of general file descriptor monitoring.
	MonitorPcap( pcap );
	return 0;
	}

view raw libpcap_live_capture.c hosted with ❤ by GitHub

Grepping for Multiple Patterns at Once

Grep is a tool with which every programmer should be familiar. It is easy to use to grep to search a text file for lines matching a particular pattern, but sometimes it useful to search a text file for multiple patterns. You can accomplish this by switching over to the egrep command. For example,

egrep 'my|example|search' myfile.txt

will search myfile.txt for all lines which contain either the string "my", "example", or "search".

Using ArrayLiteralConvertible to initialize swift OptionSetType objects

I was recently working on a program where I needed to configure the autoresizingMask property of a CALayer object. The autoresizingMask property is a bitmask of CAAutoresizingMask enum values. I got a little bit confused because the example code I was following was no longer valid swift:

layer.autoresizingMask = CAAutoresizingMask.LayerWidthSizable | CAAutoresizingMask.LayerHeightSizable

view raw OldStyleOptionSetType hosted with ❤ by GitHub

The first thing I tried was to initialize the CAAutoresizingMask manually, but this code looked ugly:

layer.autoresizingMask = CAAutoresizingMask( rawValue: CAAutoresizingMask.LayerWidthSizable.rawValue | CAAutoresizingMask.LayerHeightSizable.rawValue )

view raw ManualAutoresizingMask hosted with ❤ by GitHub

Then I discovered that OptionSetType objects implement the ArrayLiteralConvertible protocol. This gives an OptionSetType the ability to be initialized with array style syntax. The most concise way to initialize a CAAutoresizingMask object is as follows:

layer.autoresizingMask = [.LayerWidthSizable, .LayerHeightSizable]

view raw ConciseCAAutoresizingMaskInitialization hosted with ❤ by GitHub

Variable Coding Guidelines

One thing that separates good programmers from great programmers is the way great programmers use variables in their code. Great programmers:

• Use clear and concise variable names. One letter variables names are acceptable when used in conventional ways recognized by everyone, like loop indices, but almost nowhere else. Variable names should use full words either in camel case (int maxTreeDepth;) or separated by underscores (int max_tree_depth;).
•  Declare variables as close to where they are used as possible, and within the smallest scope possible. This has a number of benefits:
• Variable "live time" is reduced. Live time can be thought of as the space between where a variable is declared, and the time it is used. Keeping this space small reduces the chance that a variable will be modified in an unexpected way, perhaps by a future maintenance programmer, before your code uses it.
• It makes refactoring a large function into a number of smaller functions easy. If all your variables are declared at the top of the function you are refactoring, you will need to extract the variables required by each new, smaller, function one by one. If the variables are declared immediately before they are used, the refactor becomes a simple copy and paste operation. 
• Do not reuse variables. There are some exceptions to use rule, but in general, a variable's name should be so specific that it would not make sense to reuse it for another purpose within the same scope.
• Have empathy for people who will be reading their code in the future. I read a lot of code where programmers go to great lengths to use tiny variable names and obscure abbreviations. I think there are two possible causes for this type of programming:
• Sheer laziness. Many stubborn programmers refuse to learn how to use modern IDEs which are capable of doing newfangled things like auto-completing variable names. As a result, these types of programmers want variable names to be as small as possible, so they do not have to type as much as if they were using good variable names.
• Nerdy chest-thumping. Some programmers are capable of keeping all of the details of a complicated algorithm in their head using nothing but terse 1-5 character variable names. As far as I am concerned, there are only two possible explanations for this type of design. Either you don't care about the people who are going to be reading and maintaining your code in the future, or you are insecure and you want those reading the code to be impressed with how few characters your algorithm required.

NSMenuItem Troubleshooting

Every now and then I run into a problem where a NSMenuItem stays disabled when I think it should be enabled. If you are having a similar problem, here are a few things to check:

• Make sure the NSMenuItem is hooked up to an action. If a menu item has no action it will never be enabled.
• Check your validateMenuItem: implementation. Is it setup to reject menu items it doesn't know about?
• Is the menu item's tag set correctly?
• Does your application have multiple validateMenuItem: methods? If so, make sure you are debugging the correct method. The method you need to look at is the one implemented by the class whose action the NSMenuItem will trigger. This can be a bit confusing if the target of the action is the First Responder object.

Monitoring Files Asynchronously for Reading

There are a number of ways to monitor file descriptors asynchronously to determine when data is available to be read. Calling select() directly is getting to be old fashioned, but it still gets the job done. Because select() can block until data is available to be read, it should only be called from a background thread in a GUI application. In a daemon, it can be called from the primary thread as long as the daemon doesn't need to do anything else while it waits for data to become available.

	#import <sys/select.h>
	void MonitorFiles( int fileDescriptor1, int fileDescriptor2 )
	{
	fd_set allFileDescriptorSet;
	FD_ZERO( &allFileDescriptorSet );
	FD_SET( fileDescriptor1, &allFileDescriptorSet );
	FD_SET( fileDescriptor2, &allFileDescriptorSet );
	int maxFileDescriptor = MAX( fileDescriptor1, fileDescriptor2 );
	for( ;; )
	{
	fd_set readFileDescriptorSet = allFileDescriptorSet;
	int readyCount = select( maxFileDescriptor + 1, &readFileDescriptorSet, NULL, NULL, NULL );
	if( readyCount < 0 )
	{
	// Error
	break;
	}
	if( FD_ISSET( fileDescriptor1, &readFileDescriptorSet ) )
	{
	// Read data from fileDescriptor1
	}
	if( FD_ISSET( fileDescriptor2, &readFileDescriptorSet ) )
	{
	// Read data from fileDescriptor2
	}
	}
	}

view raw select.c hosted with ❤ by GitHub

The kqueue API is similar to select, and has the same limitations with respect to blocking threads.

	void MonitorFiles( int fileDescriptor1, int fileDescriptor2 )
	{
	int kq = kqueue();
	if( kq < 0 )
	{
	// Error
	return;
	}
	struct kevent monitorList[2];
	EV_SET( &monitorList[0], fileDescriptor1, EVFILT_READ, EV_ADD | EV_ENABLE, 0, 0, 0 );
	EV_SET( &monitorList[1], fileDescriptor2, EVFILT_READ, EV_ADD | EV_ENABLE, 0, 0, 0 );
	struct kevent eventList[2];
	for( ;; )
	{
	int eventCount = kevent( kq, monitorList, 2, eventList, 2, NULL );
	if( eventCount < 0 )
	{
	// Error
	break;
	}
	for( int i = 0; i < eventCount; i++ )
	{
	// Check eventList[i].flags for errors
	// eventList[i].ident is the file descriptor that triggered
	// the read event
	readDataFromFileDescriptor( eventList[i].ident );
	}
	}
	close( kq );
	}

view raw kqueue.c hosted with ❤ by GitHub

Using libdispatch is a better option for GUI applications. The file descriptors can be monitored on a background thread and processed on the main thread.

	void MonitorFileDescriptors( int fileDescriptor1, int fileDescriptor2 )
	{
	dispatch_source_t fd1Source = dispatch_source_create( DISPATCH_SOURCE_TYPE_READ, fileDescriptor1, 0UL, dispatch_get_main_queue() );
	dispatch_source_set_event_handler( fd1Source, ^{ readDataFromFileDescriptor( fileDescriptor1 ); } );
	dispatch_source_set_cancel_handler( fd1Source, ^{
	dispatch_release( fd1Source );
	close( fileDescriptor1 );
	} );
	dispatch_resume( fd1Source );
	dispatch_source_t fd2Source = dispatch_source_create( DISPATCH_SOURCE_TYPE_READ, fileDescriptor2, 0UL, dispatch_get_main_queue() );
	dispatch_source_set_event_handler( fd2Source, ^{ readDataFromFileDescriptor( fileDescriptor2 ); } );
	dispatch_source_set_cancel_handler( fd2Source, ^{
	dispatch_release( fd2Source );
	close( fileDescriptor2 );
	} );
	dispatch_resume( fd2Source );
	// Must call either dispatch_main(), [[NSRunLoop currentRunLoop] run], or CFRunLoopRun()
	}

view raw gistfile1.txt hosted with ❤ by GitHub

Using NSFileHandle is an even simpler option for GUI applications. The only caveat is that the readability handler is called on a random thread. If you need to update your UI in response to something read from the file descriptor, you will need to move over to the main thread.

	void MonitorFiles( int fileDescriptor1, int fileDescriptor2 )
	{
	NSFileHandle * fh1 = [[NSFileHandle alloc] initWithFileDescriptor:fileDescriptor1 closeOnDealloc:NO];
	fh1.readabilityHandler = ^( NSFileHandle *fh ) {
	// readabilityHandler is called on a random thread. Move it back to the main thread
	dispatch_sync( dispatch_get_main_thread(), ^{ readDataFromFileDescriptor( fh.fileDescriptor ) } );
	}]
	NSFileHandle * fh2 = [[NSFileHandle alloc] initWithFileDescriptor:fileDescriptor2 closeOnDealloc:NO];
	fh2.readabilityHandler = ^( NSFileHandle *fh ) {
	// readabilityHandler is called on a random thread. Move it back to the main thread
	dispatch_sync( dispatch_get_main_thread(), ^{ readDataFromFileDescriptor( fh.fileDescriptor ) } );
	}]
	// Must call either [[NSRunLoop currentRunLoop] run] or CFRunLoopRun()
	}

view raw NSFileHandle.m hosted with ❤ by GitHub