curses setjmp/longjmp

In 1992, I was maintaining a UNIX inventory system that was developed around a screen template system that used the curses library to implement a pretty standard menu tree with data screens as leafs:

My job was to add a new screen, the red box, and the red transition lines to do a master-detail pair of screens. 

The way this system worked is that a set of screen definition files would be run through a code generation program to generate the C code that would keep track of the menu path and the fields in the data screens.

Each of these screens would have a 80x24 template with field names following by a special replacement character for different field types.  For example, you could have a part of the screen say:

Ship Date: MM/DD/YY

or

Comments: @@@@@@@@@@@@@@@@@@@

and the code generator would create all of the code necessary to define structures that had a ship_date members and a comments member, handle moving from field to field with the tab key, etc. along with very simple character based data validation (MM was 01-12, DD was 01-31, @ was any text character).

The underlying custom library had two interesting features which complicated development:

1. Moving between the menu and data screens was done via setjmp()/longjmp(). When leaving the menu definitions, the code would call setjmp().  When the changes were completed or aborted in the data screens, the code would call longjmp() to return.  This simplified the screen code generation because it didn't need to keep track of the various paths.  It was an implementation of GOTO considered harmful in the wild.
2. Event tracking in the C code was for individual key strokes and it was tied quite closely to the curses interface.

This created the following issues I needed to overcome:

• I now had two levels of setjmp()/longjmp(), so I needed a way to execute the right longjmp() buffer when existing screens.
• I also had the possibility of a loop in the screens because the new requirements allowed moving from one data screen to another.

With the benefit of coding in X-Windows, Motif, Java Swing, and more AJAX libraries than I care to remember, the best practice way to deal with this problem would have been to implement a reactor pattern that would have moved the state management out of the C stack and into a real data structure.

But I didn't know that then, so that's not what I did.  What I did was break more rules.

First, I created a global stack data structure of pointers to setjmp()/longjmp() buffers.  This way, when I entered a page, in addition to calling setjmp(), I would also push the buffer onto the stack.  When I left the page I could pop the next buffer off of the stack and be ready for the next longjmp() call.

Second, I had to deal with the possibility that the user could move back and forth from data screen to data screen, each time adding a buffer entry to the stack.  I worked around that problem by generating synthetic events that would move from screen to screen via the existing menu structure:

So transitioning from one data screen to another performed the expected longjmp() call which was then followed by made up events to navigate back down to the correct screen, breaking the graph cycle and making the design work correctly.

What to take away from this tale?

• Don't make a library boundary something that prevents you from finding a better solution to a problem.  The whole refactoring methodologies and practices have been created specifically so you don't make this same mistake.
• If refactoring isn't an option, you can work around technical boundaries, but you may have to break some rules to do so.