Re: gEDA-user: PCB Polygon code (with r-tree speedups) triggers GCC bug...

[der Mouse <mouse@xxxxxxxxxxxxxxxxxxxx>]

> 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		mouse@xxxxxxxxxxxxxxxxxxxx
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user