TERMIO save/restore seems wacky

[Jeff]

Ok, all you wizards, please explain what is happening here.
The following function extract are from a program I wrote
to take input from a file and feed it to an executable shell a 
line at a time.  This involves going into raw mode, obtaining a
function key that determines what action to take with the command
buffers, and then returning to cooked mode to execute the
command.

.....
static struct termio tbufcooked;
static struct termio tbufraw;
...
void set_cooked()
{
    (void) ioctl( 0, TCSETAF, &tbufcooked );
}
...
void set_raw()
{
    (void) ioctl( 0, TCSETAF, &tbufraw );
}
...
void init_raw()
{
    (void) ioctl( 0, TCGETA, &tbufraw );
    tbufcooked = tbufraw;

    tbufraw.c_iflag &= ~(INLCR | ICRNL | IUCLC | ISTRIP | IXON | BRKINT );
    /*
     * recommended by GP - seems to work with this removed!!
     *
    tbufraw.c_oflag &= ~OPOST;
     */
    tbufraw.c_lflag &= ~(ICANON | ISIG | ECHO );
    tbufraw.c_cc[4] = 1;
    tbufraw.c_cc[5] = 10;
}

The bizarre problem occurs with OPOST.  If I toggle OPOST, then after
the retrun to cooked the output from the sub-shell does the normal trick
of heading rapidly for the right marginand piling up there.
With OPOST untouched all works well.

My question is WHY???  Why does saving, toggling, and then restoring
OPOST not act the same as ignoring OPOST in the first place.

I am running XENIX 2.3 i80286

Thanks muchly for suggestions.  I have the program working, but I
am still poozled.
-- 

  ----------------------------------------------------------------------------
  | Jeff Tate              |     2425 Pandora Street, Vancouver, BC, Canada  |
  | van-bc!softop!jeff     |                                 (604) 254-4583  |
  ----------------------------------------------------------------------------