Well, too bad I found that patch rather late, as it covered a
bit more than was described in the subject, so I meanwhile
fixed the exit spec processing in CVS already.  However, the
previous method was moderately broken anyway, and required
quite a bit more work than just moving the code from main.c
into par.c.

Now after some googling around, I think I basically understand
the point of bit 0x20 in the control register, but I came to
the conclusion that AVRDUDE should rather stay away from
touching it.  If at all, that bit should be cleared upon
initialization (to ensure the output drivers will be enabled),
and it will be restored upon exiting anyway.  The point of the
other "exit specs" is to ensure certain characteristics of
the attached programmer/AVR after exiting, but somehow, I don't
see how this would apply to the "bidirectional" bit as it is
not routed to the programmer.

Well, now upon thinking about it, I can imagine one reasoning:
on an unbuffered programming adapter, it could be used to
tri-state the parallel port upon exit.  Depending on whether
the operating system really reprograms that pin later on
when it tries to print something, this could have funny
side-effects...

Also, as the current model of the exit specs differs from the
one when this patch has been created, the patch would have to
be re-done.  The current model works on the logical pin level,
i. e. it remembers whether to set or clear the "reset" line
(some of the bits could be attached to more than one pin),
rather then remembering which IO pin to set or clear.  The
translation from the logical meaning to the physical pin is
then done using par_setpin() at exit time after restoring
the previous port register values.

If we decide to integrate a patch like that one, I suggest we
do the following:

. add another logical pin name
. programmers that are interested in manipulating the
  output buffer enable should specify that pin (using a
  pseudo pin number?)
. AVRDUDE ensures the output drivers are always enabled
  at start-up time
. if the exit specs tell us, they can just be processed the
  normal way to set or clear that signal (using par_setpin()).

When reading the comments in the patch, I think that even
matches your ideas...  Sorry it took so long to get back on
this.