The *scrapping* of setjmp/longjmp :-(

[Maiko Langelaar (ve4klm)]

Greetings,

I realize this is a bit late in coming, but I had to say something.

I am a developer for an application that has been around for quite some
time - JNOS. There are other variants as well, such as TNOS, etc. This
software is common to the Amateur Radio community, much of it based on
the original KA9Q NOS by Phil Karn.

I know there's a thing called natural progress, old things die, new
things come in. What I want to do here, is simply let people know my
feelings on the decision to essentially eliminate the JMPBUF stuff.

I would just like to understand the reasoning behind why  - on jumping
to Fedora Core 5 - suddenly our applications break. I know exactly why
they break, what I would like to know is why did support for the JMPBUF
mechanism suddenly get removed from GLIBC without any regard to existing
applications that strongly depend on it.

Who deemed setjmp and longjmp to be obsolete, when there are developers
out there that clearly still use it, and their applications work quite
well, without problem. Sure I can convert our kernel code to UCONTEXT,
but why should one have to it *it's not broke*. Our applications worked
fine, even in Fedora Core 4. The so called technical issues as to why
it's *dangerous* to use setjmp/longjmp really did not rear themselves.

I'm not looking for flames here, and I think it's fair enough to post
feedback to the developers in a civil manner, that their decision will
have essentially put an end to an elegant and still very functional style 
of programming used by the select few software developers out there that
want and know how to use the JMPBUF mechanism.

Back in April 10, 2006, Marc Dionne had written :

> In recent versions of glibc, setjmp() now mangles the stack pointer when
> it stores it and unmangles it in longjmp(). I suspect your code is
> trying to change the stack pointer (since it uses the offset), which
> won't work unless it knows how to mangle it properly.

Could a mangle function not be created, so that if an application wants
to change the stack pointer, it could be called. I mean, if setjmp() now
mangles the pointer, then why can't that mangle function be avialable
to the user.

> Some options are to implement the mangling algorithm in the code
> (which is platform specific and will be a pain to maintain)

But setjmp() is mangling it already, so it looks like there has to
be a mangling function already, why not make it *public* ?

> switch to using setcontext/makecontext/getcontext. That's what was done
> in OpenAFS to support FC5.

Which I've reluctantly had to do for Fedora Core 5. I read postings of
the OpenAFS experiences about a month ago, and found it very interesting.

Ulrich responded back then :

> That value was never meant to be used by programs.

Says who ? What harm was there in leaving it there, especially when 
there are a select group of programs that worked fine with them.

> It was a value needed in the implementation and unfortunately it was 
> placed in the public header.

I wouldn't call that unfortunate. BorlandC did a great job of it, letting
us write task schedulers in DOS, then migrating stuff to linux. I think it
was a rather nice feature to have.

> This is fixed now. And for a good reason: you cannot access the
> values at all anymore today.  The stored values are "encrypted".

And to some of us (speaking for myself anyways), that's unfortunate.

What's next ? UCONTEXT will be scrapped ? I'm not afraid of threads,
but there are benefits for our particular type of software to continue
to use JMPBUF, are at minimum UCONTEXT.

Anyways, I suppose this is called progress. I'm not bitter about this,
just wanted to give some feedback that's all, and get a better 
understanding as to why the decisions made, were made.

Sincerely,

Maiko Langelaar
maintainer/developer JNOS 2.0 Project
http://www.langelaar.net/projects/jnos2

----

  Maiko Langelaar, Department of Physics & Astronomy
  IT Group, Room 208, Allen Building, Phone 474-9273