Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!umn-d-ub!cs.umn.edu!mike From: mike@umn-cs.cs.umn.edu (Mike Haertel) Newsgroups: comp.lang.perl Subject: Re: Bugs in perl 3.0 pl 8 -- return statement Message-ID: <1990Feb15.202214.14987@umn-cs.cs.umn.edu> Date: 15 Feb 90 20:22:14 GMT References: <4080004@hpausla.aso.hp.com> <4080005@hpausla.aso.hp.com> <418@proexam.UUCP> <7000@jpl-devvax.JPL.NASA.GOV> <7068@jpl-devvax.JPL.NASA.GOV> <5716@videovax.tv.tek.com> <7080@jpl-devvax.JPL.NASA.GOV> Organization: Free Software Foundation Lines: 19 In article <7080@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >Ok, I'll spread a few more judicious volatiles here and there on my globals >and structure elements. Blech. All this gobblygook just to make life >a little easier for a few compiler writers. setjmp()/longjmp() are NOT >in the same class as asynchronous interrupts. > >"volatile" must go. This is non-negotiable. :-) :-) :-) Note that if -traditional is used with gcc, it automatically recognizes functions that call setjmp() and effectively forces all references from within those functions to be volatile. Of course, particularly if you call setjmp() from somewhere within a big, oft-used function, this is an efficiency hit, so volatile declarations may be more appropriate, if more work. -- Mike Haertel "COBOL programmers are destined to code COBOL for the rest of their lives, and thereafter." -- Bertrand Meyer