The other day I ran into an interesting problem: how can you write a C preprocessor macro that removes parentheses surrounding its argument, but leaves the argument alone if no parentheses are present? For today's article, I'm going to share my solution.

This is my first guest Friday Q&A article, dear readers, and I hope it will withstand your scrutiny. Today's topic is on Mach exception handlers, something I've recently spent some time exploring on Mac OS X and iOS for the purpose of crash reporting. While there is surprisingly little documentation available about Mach exception handlers, and they're considered by some to be a mystical source of mystery and power, the fact is that they're actually pretty simple to understand at a high level - something I hope to elucidate here. Unfortunately, they're also partially private API on iOS, despite being used in a number of new crash reporting solutions - something I'll touch on in the conclusion.

This is something of a followup to my last article, dyld: Dynamic Linking On OS X, in which I explored how the dynamic linker dyld does its job. This week, I'm going to recreate the function of both the compiler and the static linker, building a Mach-O binary completely from scratch with only the help of the assembler.

It's been a bit since I did an article, but I'm back again, with a somewhat off-the-cuff treatment of a very twisted set of code I use to pretend that C has exceptions. I delve into little-known extensions of C, Linux compatibility, and worst of all, goto, so be warned!

Every once in a while, when writing threaded code, you may find yourself wanting to acquire two different locks in a critical section. Normally one should resist such perversions, but sometimes they just end up being necessary, or too tempting. Holding multiple locks at the same time immediately raises the specter of deadlock: if two threads acquire the same locks in a different order, they can end up waiting on each other forever.

Last time, I talked about my crazy hack that misuses the Objective-C message forwarding machinery to do block proxying. This allows writing code that interposes in front of an arbitrary block to intercept its arguments, manipulate its return value, etc. Today, I want to present an exanmple of using this hack which almost verges on the practical. Specifically, I'm going to discuss how to use it to build a generalized block memoization facility.

Here at Friday Q&A, I pride myself on occasionally taking my readers to places where normal people dare not tread. Today is one of those days. This is not a reader suggested topic, but today I want to talk about a fun hack I came up with that allows proxying block invocations in much the way that one can proxy Objective-C messages.

It's time for another friendly edition of Friday Q&A. For my last Friday Q&A, I talked about MAZeroingWeakRef and how it's implemented for pure Objective-C objects. For this one, I'm going to discuss the crazy hacks I implemented to make it work with toll-free bridged CoreFoundation objects as well.

Welcome to another edition of Friday Q&A, where deep technical talk and complete insanity combine! This week, I'm going to take a quick break from my usual reader-driven format and talk about a little toy I built earlier in the week, an adapter between blocks and more traditional function-pointer-based callback systems.

It's that time of the week again. For this week's Friday Q&A Mike Shields has suggested that I talk about method replacement and method swizzling in Objective-C.

It's well known that every member of the official iPhone developer program is bound by Apple's iPhone SDK agreement. What seems to be much less well known is that the agreement also binds developers to follow Apple's "Copyright and Trademark Guidelines", which add a huge list of restrictions to what an iPhone developer can and cannot do.

It's Friday again, and that means another Friday Q&A. This week, Guy English proposed talking about a blocks-based object system, and that is what I will do. The system I've developed is a rudimentary system for doing object-oriented programming in pure C (plus blocks), and I'll discuss how it works and how to use it.

Welcome back to another exciting Friday Q&A.; This week I'll be taking Jonathan Mitchell's suggestion to talk about code injection, the various ways to do it, why you'd want to, and why you wouldn't want to.

The winners of the 2006 IOCCC have been posted. Sadly I am not among the winners this year, but the winners all appear to be most deserving.

The International Obfuscated C Code Contest is a contest with the goal of creating the most unreadable, difficult-to-understand C program possible. Aside from being difficult to understand, the judges tend to prefer programs which do clever or interesting things, or which do mundane things in clever, interesting, or weird ways.