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

[Peter Clifton <pcjc2@xxxxxxxxx>]

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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user