> I guess I'll have to look out for any stack variables used in the > routines which use setjmp / longjmp, and make sure they are not going > to cause trouble.
> Since PCB works, I'll assume that the likelihood of that case is low. On *most* current systems, *most* objects retain their values, even if they're auto and non-volatile. The usual case that causes trouble is when the object happens to be kept in a register across the call which ends up longjmping; when longjmp unwinds the stack and restores registers, it restores the object's value as well. But the C people wisely decided not to try to cast the current problematic cases in stone as the only allowed-to-be-problematic cases, to allow more latitude in the implementation of setjmp and longjmp (and, quite probably, to avoid making it impossible to implement without ruinous efficency penalties on some of the more arcane architectures). Making such objects "indeterminate" rather than "changes may be rolled back" allows things like part of an object being in memory (and thus not rolled back) and part in a register (and thus rolled back). And, of course, there's no guarantee that longjmp is implemented that way.... So don't assume that the code is correct just because it currently doesn't break. The chances of being bitten by this issue at the moment are low, even for buggy code, but the next compiler release may include a more aggressive optimizer, or just a different code-generation module, and render such bugs blatant instead of latent. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user