On Tue, 2009-02-24 at 12:49 -0500, Ethan Swint wrote: > I don't know how well gcc optimizes around jumps - but it looks like > longjmp restores some of the environment. Could it be that 'first' is > being restored to its initial value of '1'? Try printing the value of > 'first' before the conditional is evaluated.
That would seem to be the case.. > It would seem to me that a more suitable workaround would to be to put > this bit of code in a while or do-while loop - unless you are counting > on specific bits of the environment being restored to their state when > setjmp() is called. setjmp / longjmp is being used to short-circuit the return of a recursive r-tree search call, so is required. It can just be a little mind-bendy to get your head around the execution flow, and potential side-effects (which is what bit me). The linux man page has this to say: "setjmp() and sigsetjmp() make programs hard to understand and maintain. If possible an alternative should be used." Well, I think in PCB at least some of their use is quite justified, even if in places it is a nightmare to follow the execution flow. Fortunately, the "worst" use of these functions is contained in the polygon handling routines, and IIRC for error trapping / shortcut returns in the DRC code. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
