Behaviour of setjmp/longjmp and registers

[Robert Claeson]

In article <9480 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn ) writes:

> Really, setjmp/longjmp is just a groady "goto" and should be
> avoided for the same reasons as the ordinary "goto"...

> it is even more violent than an ordinary "goto", which is why
> it has to be more loosely constrained.  I don't think I've
> even seen a case in which setjmp/longjmp was the best way to
> design code, let alone essential.  The nearest to a valid use
> I know of is to allow a SIGINT to abort processing and fly
> back to a main command loop (e.g. in the "ed" editor), but
> even there the longjmp can cause stdio data structures to be
> left in an inconsistent state.  Asynchronous concurrent
> processes really need to be designed around better tools than
> setjmp/longjmp.

Okay, all you portable code types, maybe you can help me with making
this more portable (ie, to not use setjmp/longjmp).

In a single-key (not character) keyboard read routine I've written,
I recognizes function keys and returns a single, generic value for them
instead of the usual character. I do this by setting an alarm(1) and
reading character by character until I've got a non-redundant string, which
in the case of a printable character (an 'a' for example) is that single
character.

If a complete function key sequence is found before that alarm() is
performed, the alarm is cleared and a value is returned.  But if I
keep reading from the keyboard without finding a  real key, a SIGALRM
handler is called, which just does a longjmp back to  a setjmp in the
main (non-static) function. Then the complete string, except for the
first character, is stored in a buffer that will  be read instead of
the keyboard on subsequent calls to the function. The first  character
read is returned. This is how I handles single Escape keystrokes.

I could  probably read the clock, do a tight  loop  that reads the
keyboard non-blocking and check the clock on each iteration, but  that
would probably take too much CPU, so I don't want to do that.

Now, make this portable and non  CPU-intensive. If you think the
algorithm needs to be changed, just tell me.
-- 
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
"No problems." -- Alf
Tel: +46 758-202 50  EUnet:    rclaeson at ERBE.SE  uucp:   uunet!erbe.se!rclaeson
Fax: +46 758-197 20  Internet: rclaeson at ERBE.SE  BITNET: rclaeson at ERBE.SE